은행은 왜 이렇게 오래된 인증서 알고리즘 / 암호화 알고리즘을 쓰는 걸까

Disclaimer: 작성자 본인은 암호학 전문가가 아닙니다. 이글에선 무엇도 보장하지 않고 이글을 참고해서 하는 일에 대해선 어떤 책임도 지지 않습니다.

국민은행이 모던 브라우저에서 인터넷 뱅킹이 된다기에 시험 해 봄. 근데 들어가자마자 뜨는 워닝이 너무 우울해서 몇 가지를 확인.

국민은행 접속 시 뜨는 경고

인증서가 SHA1 해시를 이용

인증서가 유효한지 확인하기 위해서는 해당 인증서가 유효한지 확인하기 위해 인증서의 해시 값을 구하고, 이를 서명해둔다. 이 때 암호화 해시 함수; cryptographic hash function 을 이용하는데, 여기서는 SHA1 해시 함수를 쓰고 있더라.

현재 구글이나 모질라에서는 SHA1 대신 그 보다 안전한 다름 함수를 쓸 것을 권한다. Bruce Schneier는 2012년에 2015년이면 약 USD 700k 정도면 충돌하는 다른 해시 값을 찾을 수 있다고 추정 하기도 했다. 즉, 현실적으로 저 해시에 해당하는 인증서를 위조(…)할 가능성이 생긴다. 게다가 인증서가 2015년에 생성한 것이던데.

암호화 알고리즘이 구닥다리 (no PFS!)

지원하는 암호화 알고리즘 조합이 키 교환은 RSA만 이용하고 — 그래서 키가 털리면 이전 모든 통신을 복호화해 볼 수 있고 — 메시지 암호화 알고리즘도 AES-128/256-CBC 나 RC4, 3DES-EDE (…) 를 지원한다. 세션 동안만 유효한 암호화 키 (ephemeral key)를 쓰지 않는다. 으으 지금은 2015년 같은데. 게다가 쓰지말라고한지 2년은 된 RC4?

게다가 아직 SSL v3가 남아있다. 혹시 POODLE이라고 들어는 보셨는지… 다행히 TLS_FALLBACK_SCSV 를 써서 TLS v1 이상을 쓰는 브라우저로 접속하면 당장 문제는 아니긴하겠지만.

그들을 위한 변명 …

SHA1 알고리즘의 대체인 SHA2의 호환성을 확인하자면, 클라이언트가 Windows XP SP3 (!!) 이후면 문제가 없다. (DigiCert의 해당 안내문 ) 아직도 Windows XP SP2 + IE6를 쓴다면 이런 인증서를 써야할 수…는 있다.

RC4의 문제도 실제로 이게 선택되는 조합은 Qualys SSL LABS 결과엔 없다. (그럼 걍 빼지…).

SSL v3는 Windows XP + IE6 를 지원하려면 필요하긴 하다.

근데 이것 때문에 FS를 위한 키교환 알고리즘을 못 쓸 이유는 없는 점은 변명의 여지는 전혀 없음. 그리고 이런 사용자 (Windows XP + IE6)는 은행이 책임져 주지도 않는데 차단 할 일이지, 이걸 위해서 다른 사용자가 더 약한 암호화/인증서를 쓸 이유는 안된다.

기왕 모던 브라우저 지원하는 김에 버릴 건 버리고 가는게 맞지 않을까?

그래프 가지고 장난치지 말자 #2

며칠 전에 트위터를 떠돌던 모 그래프를 보고.

트위터에 인용된 그래프
트위터에 인용된 그래프

나는 이런 그래프에 굉장히 불만이 많은데 (이전 글 참고), 그래프를 그린이의 의도에 완전히 좌우된 듯한 인상을 준다.일단 밑부분이 잘려나간것 자체가 최악.

그리고 인용하는 사람들의 문맥도 의도가 너무 들여다보인다. 나도 리트윗 했던 것 같지만(…).

 

저 그래프에 나온 소스를 찾아가서 그 데이터로 한 번 그래프를 다시 그려봤다. (참고: OECD 통계 데이터 사이트)

일단 저 데이터가 2007년까지의 데이터만 있는데 그 이후로도 한국의 상황은 좀 더 나아졌다 (…).

1. 우선 인용된 그래프 비슷하게 그려본 것. Y축 최소값이 0이 아닌게 매우 맘에 안든다

(위 그래프랑 거의 비슷한 점만 봅시다)

국가별 연간 근로시간 (1500)
국가별 연간 근로시간 (1500)

 

2. Y축 범위를 0부터 그리게 수정

한국이 프랑스 두 배쯤 일하다가 1.5배쯤 일하는걸로 좋아(…)졌다.

국가별 연간 근로시간 (0)
국가별 연간 근로시간 (0)

 

3. 비슷하게 우울한 나라들을 추가

한국 정도로 우울한 나라를 몇 개 추가했다. (아예 상승 중인 러시아를 포함해서 멕시코와 칠레 추가)

국가별 연간 근로시간 (more)
국가별 연간 근로시간 (more)

4. 생각 정리

한국이 우울한 건 맞다. 한국의 수준을 냉정하게 생각하면 아주 나쁜건 아니지만 좋은건 절대 아닌 정도?

다만 원본 그래프 자체가 의도가 이상하고 (왜 한국만 껴 넣었을까? 일본 언론이라?), 사람들이 축 이상하다고 축을 까는데 그 고친 축도 이상해 (…) 라는 게 내 생각.

예비군 통지서를 샾메일로 보내는 것 혹은 그거에 대해 권장하는 행위에 대해 해야할 일

국방부에서 예비군 통지서를 샾메일[1] 을 사용하겠다는 얘기를 한다:

국방부는 이번 예비군훈련 소집통지 샵(#)메일 체계를 국방동원업무체계와 연동, ‘13년 10월말까지 구축하고 금년 말까지 시범사업을 추진할 계획이다

○ 이를 위해 현재 예비군중 희망자와 매년 전역하는 약 22만명의 신규편성 예비군을 대상으로 샵(#)메일 통지 체계를 구축할  계획이며 앞으로 예비군들이 샵(#)메일 체계를 이해하고 이용을 확대할 수 있도록 적극 홍보할 계획이다

 

심지어 예비군 훈련 받으러가니 이메일도 번거롭고 전화도 번거로우니 수신 확인되는 (…) 이 멍청한 방식을 사용하려하니 이걸 권장한다고 말하더라. (예비군 동대장인듯?)

그에 대한 나의 대응은 다음과 같다:

  • 예비군 웹사이트에서 email 주소 제거
  • 예비군 웹사이트에서 전화 번호 제거

만약 나에게 전화가 걸려오거나, 이메일이 날아오면 내 개인 정보에 대한 충분한 보호책을 사용하지 않는 걸로 보고 아주 ㅈㄹ을 해봐야겠다.

타인에게 *악의*에 가까운 불편을 끼치려면 자기도 불편할 수 있음을 인지해야하지 않겠나?

  1. 이름에 메일이 들어있지만 rfc822부터 시작된 email 표준과는 전혀 무관하다 []

절전 정책인지 뭔지

최근 회사에서 아주 죽을 맛이다.

정부의 절전시책인가 뭔가로 회사에서 냉방기 — 난방기 아님 — 사용을 금지하고, 공조 시설 가동을 최소화 한단다.
그 결과가 뭐냐하면, 이 한겨울-_-에 28도까지 올라가서 일하기 괴로운 사무실.

심심하신 분은 고성능 CPU/GPU의 면적당 발생하는 열량을 계산해보시기 바람. 항성 표면(…)에 준하는 수준임…
이런걸 2~3개씩 달고 있는 PC를, 사람마다 k개 (2~5?), 그리고 팀 별로 공용 장비로 들고있는 것 까지 생각하면 발생하는 열은 좀 삭막한 수준; 

이 정부가 친환경 성장 정책에 전혀 관심이 없다고 느껴지는게,

  • 전기가 모자란 것 일단 사실이 아닌 것 같고 — 발전소 가동률을 볼 때
  • 산업용 전기료를 인상할 생각은 없는듯 함; 가정용 수준으로 올리거나, 가정용처럼 누진제를 적용해야 함
  • 상대적으로 온실 가스 방출량이 적은 기업에도 전기 사용량 제한

정도?

재작년엔가 여름에 27도 제한했을 때도 미치는 줄 알았는데, 겨울에도 이런 꼴을 보게 해주다니 아주 짜증나 죽겠다.
 

그래서 오늘은 창문을 열어놔 봤다. 대략 25도?까지 떨어지긴 하던데,

  • 테헤란 로를 달리는 차들의 경적 + 기타 소음
  • 매연
  • 가끔 찬 바람이 직접 닿기

…를 경험하고 나니 Orz.

정말 꿈도 희망도 없어…

그래프 가지고 장난치지 말자

http://goo.gl/G97AW : 6월 3일자 매일경제의 기사다. ‘0을 포함하지 않는 그래프’를 그리고 있다. 이걸 실제로 0을 포함하는 그래프로 그리면 아래와 같은 형태가 된다.

매일경제의 잘못된 그래프

이 그래프를 놓고보면 인구 10만명 당 자살 사망자 수가 급격히 증가한 것으로 보인다. 이걸 내가 다시 그려봤다. 다만 “정직한 연구자라면 마땅히 해야할 것 같은” 형태로 해봤다.

제대로 그린 그래프

이렇게 그리면 인구 10만명 당 자살 사망자 수는 증가세인 건 마찬가지지만, 그 증가세는 훨씬 작아 보인다.

내가 대학원 시절에 배운 그래프 그리는 기본 원칙 중 하나는 다음과 같다.

  • 모든 그래프는 y축에 0을 포함해야 한다.
  • 단, log 스케일로 그릴 때는 예외로 한다.

한국의 언론이란 것들은 이런 식의 그래프를 자주 그린다. 속지 말도록 하자. 그래프는 사실을 간결하게 전달해주긴 하지만, 해당 원자료의 신뢰도, 그리고 그 그래프를 그린 사람의 의도에 따라 완전히 왜곡된 정보가 담길 수 있다.

NEIS 유감

어머니가 서울에 오셨다. 손주 보러 오신 거였는데, 근무하고 계신 학교 쪽에 행정 처리할 게 있어서 neis 페이지를 들어가야 하는데 이게 정말 가관이더라.

일단 며칠 전에 새로 열었다는 시스템에 들어갔다. 당연하다는 듯이 Windows 7(x64) + ie8 에선 안됨. 아내의 Windows 7 (x86)에서도 마찬가지.

 

“이정도로 굴복할 수는 없다”를 외치고 가상 머신으로 재시도. Active X control을 대략 1x회 설치하고도 계속 다시 설치하려고 하길래 포기. 어차피 자료 조회만 하면 어찌어찌 할 수 있는 일이어서, 조회만 된다는 이전 시스템에 접속했다.

IE8 안된다고, “이렇게 이렇게 해서 IE 8을 지워라”라는 안내 페이지가 뜬다. 물론 지우고 재시도해도 새 시스템은 접속 불가. 구 시스템은 캐 어거지로 안 깔리는 ActiveX Control 무시하고 진행하니 어찌어찌 보이기는 하더라.

 

이거 꽤나 거대 예산이 들어갔을텐데 이런 멍청한 시스템이 나오냐. 이런 걸 쓰기 위해 곧 지원이 마감되는 운영체제와 이미 구닥다리가 된 지 오래인 웹 브라우저를 쓰라고? 언제나 그렇듯이, 아주 병신같이 보안 경고엔 무조건 “예”를 선택하라고 띄우는 꼬라지하고는.

아무리 생각해도 이걸 만든 사람들이 제 정신이 아니다 — 적어도 건전한 상식인이라곤 기대하지 못하겠다. 왜 새 시스템을 — 그것도 호환 안되서 새로 넘어가는 시스템을 — 만드는 데 요즘 쓰는 환경에서 동작하질 않는단 말인가. linux나 Mac OS X에서 접속하는 것도 아니고 MS Windows인데 말이지 -_-;;  현재 쓰이고 있는 운영체제와 웹브라우저에 관심 좀 가지라는 말이다. ㅠㅠ

이거 내년 중반 예정(?)인 Windows 8과, 그 이전에 나올 IE 9이 있는 상태에선 어떤 모양일지 꽤나 궁굼하다.

 

PS. 정말 무서웠던 건, 학부모 접속 페이지 링크가 있더라. 지금 이 머신 버리지 말고(…) 애 크는 동안 보관(?)해야 하나…

 

[릴레이] 내가 서울시장이라면…

고어핀드가 던진 바통을 잡아 쓰는 글.

주제를 “육아와 출산을 경험한 입장”으로 줄여놔서 쓰는 말이라 범위가 좀 좁다. 사실 나는 세제나 종교 문제 등으로 쓸 말이 많지만…

“서울 시내 보건소의 임신/출산/영유아 관련 지원해주는 일들을 상향 평준화 하라”

가 일단 내 생각.

현재 사는 곳이 송파구…이긴 한데 강동구에 훨씬 더 가까운 곳이라(특히 구청/보건소), 강동 보건소에 좀 더 자주 간다. 하지만 안내장?은 거의 송파구의 것이 옴.

이걸 보면 좀 짜증나면서 한숨 나오는 게, 양쪽 구에서 지원하는 수준이 다르다. 송파구에선 무료인 예방 접종과, 강동구에서 무료인 예방 접종이 달랐다 (사실 이건 년도 차이일 수도 있다. 그렇지만 일관성이 없다는 점에선).

임산부 지원도 양쪽 구가 다르다. 어디는 엽산제와 비타민제를 주고(이건 주소지가 맞아야 한다), 어디는 안주고..

사실 액수로 따지면 얼마 안 되는 양이고 – 그냥 의사 조언 얻어서 따로 구입했는데도, 임신 기간 동안 들어간 돈은 10만원 미만 – 꼭 필요한 건지도 좀 의문스럽지만; 어차피 내는 지방세를 전부 구청에서 집행하는 것도 아닌데 이런 차이엔 좀 문제가 있다고 생각한다.

차라리 최소 기준 – 적어도 현재 상태보다 상향된 – 을 정하고, 이를 시 수준의 예산 집행을 통해 적어도 지금 돈 내가면서 맞는 수많은 예방 접종들과 임산/출산 지원을 해야 한다. 올해 들어간 예방 접종비만 50만원이 넘는 걸 생각하면, 출산 이후 현재 약 15개월 동안 자라는 동안 들어간 예방 접종비가 150만원에 근접해가는 걸 생각하면 더더욱;;

 

매달 꼬박꼬박 뜯기는 지방세로 한강 예술섬 같은 정신 나간 토목 사업[1] 에 투여할 게 아니라, 각 구마다 큰 차이가나는 임신/출산/육아 지원에 투입하는 게 훨씬 나아 보인다. 적어도 내가 시장이라면 그런 결정을 내리겠다. 최소한 현재 강남 3구에서 지원하는 수준으론 다른 서울 시내 자치구에서도 이루어질 수 있어야 하지 않겠나?

  1. 차 없이 접근할 수도 없는 한강 예술섬이 아니라, 대중 교통을 통해 잘 접근할 수 있는 세종문화회관이나 예술의 전당에 더 많이 지원해주는 쪽이 적절한 방안이라 생각한다. []

The Incops Strikes Back!

제목이 뭔가를 떠올리게 한다면, 그건 다 오해다. (기다려달라?)

화요일 저녁에 퇴근하려는데, 옆자리의 개발자 분이 나를 부른다. 내가 개발하는 라이브러리에서,

“Debugger 붙여놓고 띄워보면 First chance exception이 나요. Access violation 이고 0x0000 0000에 뭔가 쓰려고 합니다”

라고.[1]

일단 해당 자리의 디버거 창에서 살펴본 봐로는, 내가 수 주 전에 추가한 WSASend 호출 횟수 줄이는 코드에서 나온 문제인 듯 했다. Send-Queue에 패킷이 여러개 쌓이면, 이걸 모아서 전송하는 루틴을 추가했는데, 이 안에서 저 first-chance exception이 발생.[2] 일단 화요일엔 집에 어머니도 와 계시고 해서 바로 퇴근하고 다음 날 오전에 추적하기로 했다.

First chance exception 이 발생했다곤 해도, 프로그램이 실제로 크래시하지 않는 걸로 봐선, 어딘가에선 처리 되고 있단 얘기니 좀 안심하고 다음 날 디버깅 시작. 출근해서 코드를 열심히 들여다 봤다. 대체 어디서 문제가 생길까? 일단 내 머신에선 재현이 안되더라. 그래서 일단 저 문제를 발견한 개발자가 출근할 때 까지 기다렸다. 그리고 얘기해주는 환경을 다 끌어 모아서(플랫폼 + 컴파일러 버젼을 맞춤) 테스트.

발생하지 않는다?!?!?!?!. 해당 개발자 자리에 가서 하면 한 번에 재현된다. 그래서 잘 알려진 WinSock 관련 first-chance exception 문제처럼, 이것도 MS가 포기(?)한 버그인가 싶어서 MS에 있는 모 선배에게 물어볼까 하고 있었다. 그래도 다른 선임분의 말을 듣고 다시 디버깅하는데, 콜 스택 모듈에 보니 수상한 dll 이 하나 있더라.

anywall3.dll 이게 뭘까? 저 네이밍으로 볼 때, 저주받을(…) 삼성 SDS의 인캅스(incops)를 연상케하는데… 여튼 몇 가지 테스트를 더 해본 결과:

Incops3 가 없는 시스템에선 당연히 저 DLL이 콜 스택에 안 보인다. 그리고 저 문제도 없다….

=_=

더욱 씨니어인 다른 개발자 분의 말로는, 정확히 같은 케이스는 아니지만, 인캅스 적용 후 그런 문제를 경험하고 있다고… 나는 계속 서버 쪽 개발만해서 x64 환경만 쓰다보니 — x64에선 인캅스가 안 돈다 – 다행히 안 겪은 것 뿐이었던 듯?

결론: 개발자의 시간과 노고를 갉아먹는, 내 컴퓨터 공학 석사/학사 학위를 걸고 쓸모 없는 프로그램인 삼성 SDS Incops 좀 쓰지 맙시다. 이 회사에서도 사실 상 사용을 포기한 툴이기도 하고 – 존재 의의 중 하나가 USB 로 파일 복사를 막는 기능이 있다. 근데 “전혀 막지 못하는 버그(헛점?)”가 있는데, 리포팅하고 나서 수 개월 후에 패치는 받았다는데, 전사 적용을 못 하더라. 그리고 이젠 다른 툴을 쓴다. 인캅스 자체는 꼭 설치하지 않아도 된다고 하더라…

  1. First chance exception에 대해서는 MSDN 블로그의 이 글을 참고 하자. []
  2. 실제로 구현한 최적화는 이런 내용이다. MS Win32 WinSock 에 존재하는 시스템 콜인 WSASend 는 좀 특이하게(?)도 – 혹은 일부 UNIX 시스템에 익숙한 사람이라면 sendv() 함수를 생각하면 된다 – 하나의 바이트 스트림을 전송하는게 아니라, 일련의 바이트 스트림을 전송하게 해준다. 즉 pointer + length 를 이용하는게 아니라 pointer + length의 배열을 인자로 받아, 이를 전송해 준다. 그래서 Send-Queue에 쌓인게 많으면, 이걸 여러 번 쏘거나(system-call 수가 많다), 하나의 배열로 합치거나(추가적인 메모리 할당 및 복사가 필요하다)하지 않고, 단순히 이 버퍼들에 대한 주소 + 길이 쌍을 배열에 집어넣고 WSASend를 호출하는 것. []