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년전에 최신 C++0x를 사용을 하기 위해 Visual Studio 2013으로 컴파일러를 업그레이드 하였습니다. xp유저도 사용을 해야 하니 xp 지원모드로 컴파일을 하였는데. xp의 지원 모드로 컴파일 해도 xp sp3만 지원 합니다. 그래서.. 회사에 날라오는 XP NonSP ~ SP2 고객들의 빗발치는 항의 함께 욕만 엄청 얻어먹고… 소스코드를 구형으로 변경해서 컴파일러를 다시 2008로 내렸습니다..
그거랑 이건 다른 것 같습니다.
1. SHA1 인증서 쓰는 것: 이건 저 글을 쓰는 시점에선 변명의 여지가 있긴 합니다. 하지만 앞으로 반년도 안되는 시간 후에는 모두 지원되지 않는 웹브라우저라 조금 다른 얘기가 될 것 같고요.
2. 더 안전한 암호화 알고리즘을 지원하는 것 / PFS 를 지원하는 것: 이건 점진적인 개선이 가능하고 server-client handshake 에서 결정하는 것입니다. 그래서 오래된 덜 안전한 알고리즘을 쓸 수는 있지만, 더 안전하고 키가 털렸을 때를 대비할 수 있는 PFS 지원하는 건 “언제라도 가능한” 일입니다. 이쪽은 그냥 일을 안 하는 거라고 생각합니다.