네트워크와 인터넷 3강. 남이 못 읽게 하는 법
주소창의 자물쇠는 그 사이트가 착한 사이트라는 뜻이 아닙니다. 통로가 도청되지 않는다는 뜻일 뿐입니다.
풀고 시작
같은 열쇠와 다른 열쇠
암호의 기본형은 대칭키(symmetric key)입니다. 잠글 때 쓴 열쇠로 열기도 하는 방식이죠. 표준으로 쓰이는 AES 같은 알고리즘은 빠르고 안전해서, 지금 보는 화면의 데이터도 결국 대칭키로 암호화되어 옵니다. 문제는 수천 년 묵은 것 하나입니다. 그 열쇠를 상대에게 어떻게 전달할까요. 도청되는 통로로 보내면 열쇠부터 털리고, 안전한 통로가 이미 있다면 애초에 암호가 필요 없습니다.
공개키(public key) 암호가 이 고리를 끊습니다. 잠그는 열쇠와 여는 열쇠를 분리해, 잠그는 쪽은 공개하고 여는 쪽만 혼자 간직하는 것이죠. 열쇠 쌍은 반대 방향으로도 쓰입니다. 혼자 가진 열쇠로 만든 서명은 공개된 열쇠로 누구나 검증할 수 있고, 이 성질이 뒤에 나올 인증서의 바탕이 됩니다. 수학적 근거는 수학 서가의 RSA 강에서 다뤘습니다. 다만 공개키 연산은 훨씬 무겁습니다. 그래서 현실의 HTTPS는 둘을 섞습니다. 연결을 여는 짧은 순간에만 공개키 기법으로 이번 접속에서만 쓸 대칭키를 합의하고, 그다음부터는 그 대칭키로 빠르게 주고받죠. 최근 규약은 서버의 개인키가 나중에 유출돼도 과거 통신은 풀 수 없도록 세션마다 열쇠 재료를 새로 만듭니다.
자물쇠가 약속하는 것과 약속하지 않는 것
HTTPS가 보장하는 것은 정확히 세 가지입니다. 중간에서 엿듣는 사람이 내용을 읽지 못하는 기밀성, 오가는 중에 내용이 조작되면 수신 측이 알아채는 무결성, 지금 연결된 서버가 그 도메인의 정당한 주인임을 확인하는 인증입니다.
여기서 멈추는 것이 중요합니다. HTTPS는 그 사이트가 정직한지 말해 주지 않습니다. 사기 목적으로 만든 사이트도 인증서를 얻어 자물쇠를 띄울 수 있죠. 자물쇠는 통로가 안전하다는 표시일 뿐, 통로 끝의 상대가 좋은 사람이라는 보증이 아닙니다. 서버가 여러분의 데이터를 안전하게 보관하는지도 보장하지 않고, 어떤 주소와 통신 중인지 같은 흔적은 관찰될 수 있습니다. 보안에서 가장 흔한 사고는 기술이 실제로 약속한 범위를 넘겨 짚는 데서 생깁니다.
신뢰는 어디서 오나
인증이라는 말에는 순환이 숨어 있습니다. 서버가 보낸 공개키가 진짜 그 도메인의 것인지 어떻게 알까요. 확인하려면 또 다른 신뢰가 필요하고, 이런 식이면 끝이 없습니다. 현실의 해법은 인증서(certificate)와 신뢰 사슬입니다. 인증기관(CA)이 도메인 소유를 확인한 뒤 그 도메인과 공개키를 묶어 서명한 문서를 발급하고, 브라우저는 그 서명을 상위 기관의 공개키로 검증하며 올라가다가 미리 심어진 루트 인증서에 도달하면 사슬이 닫힙니다.
결국 우리는 미리 신뢰하기로 정해 둔 소수의 뿌리를 믿는 셈입니다. 그렇다면 뿌리가 흔들리면 어떻게 될까요. 2011년 네덜란드의 인증기관 디지노타르(DigiNotar)가 침해당해 부정 인증서가 발급됐고, 그 기관은 신뢰 목록에서 제거된 뒤 파산했습니다. 이후 발급된 인증서를 공개 기록부에 남겨 누구나 감시하게 하는 인증서 투명성이 자리 잡았죠. 신뢰의 출발점을 없앨 수 없으니 대신 감시 가능하게 만든 것입니다.
비밀번호를 저장하지 않는 서버가 좋은 서버입니다
암호화가 되돌리기 위한 기술이라면 해시 함수(hash function)는 되돌리지 않기 위한 기술입니다. 어떤 길이의 입력이든 정해진 길이의 값으로 바꾸고, 같은 입력은 항상 같은 값을 내며, 결과에서 입력을 역산하는 실용적 방법이 없습니다. 그래서 잘 만든 서비스는 비밀번호 원문을 저장하지 않습니다. 해시 값만 저장해 두고 로그인할 때 입력값을 같은 방식으로 처리해 비교하죠. 서버가 통째로 유출돼도 원문 비밀번호는 그 안에 없습니다.
그런데 해시만으로는 부족합니다. 같은 비밀번호는 언제나 같은 해시가 되므로, 흔한 비밀번호의 해시를 미리 계산해 둔 목록과 대조하면 상당수가 뚫리죠. 그래서 사용자마다 무작위 값을 만들어 비밀번호에 덧붙인 뒤 해시하는데, 이 값을 솔트(salt)라 부릅니다. 솔트는 비밀이 아니어도 됩니다. 사용자마다 다르기만 하면 미리 만들어 둔 목록이 통째로 무력해지니까요. 여기에 더해 비밀번호 전용 해시 함수는 일부러 느리고 메모리를 많이 쓰도록 설계됩니다. 로그인 한 번의 지연은 사람이 체감하지 못하지만, 대량 대조를 시도하는 쪽에는 그 느림이 그대로 비용이 되기 때문이죠.
이용자가 실제로 할 수 있는 일
여기까지는 만드는 쪽 이야기입니다. 쓰는 쪽에서 효과가 큰 것부터 봅시다. 첫째는 비밀번호 재사용을 끊는 것입니다. 여러 사이트에 같은 비밀번호를 쓰면 허술한 한 곳이 털렸을 때 그 조합이 다른 서비스에 그대로 시도됩니다. 사고 하나가 전 계정으로 번지는 통로가 재사용이죠. 그래서 비밀번호 관리자를 권합니다. 사이트마다 길고 다른 비밀번호를 쓰되 사람은 하나만 외우면 되고, 도메인을 보고 채워 넣기 때문에 가짜 주소에서는 자동 입력이 되지 않습니다.
둘째는 다중 인증(MFA)입니다. 아는 것 하나에 가진 것 하나를 더하면 비밀번호가 유출돼도 그것만으로는 로그인이 되지 않습니다. 수단마다 강도는 다릅니다. 문자 메시지는 없는 것보다 훨씬 낫지만 번호를 가로채는 방식에 약하고, 인증 앱이 그보다 낫고, 도메인을 확인해 응답하는 보안키나 패스키가 가장 강합니다. 셋째는 소프트웨어를 최신으로 유지하는 것입니다. 알려진 취약점은 대개 수정본이 나와 있고, 피해는 갱신하지 않은 곳에서 납니다. 마지막으로 암호 기술은 사람을 속이는 문제를 막지 못합니다. 여러분이 직접 열쇠를 건네주면 아무리 튼튼한 자물쇠도 소용이 없죠. 다음 강에서는 이런 서비스가 서버 여러 대로 흩어질 때 생기는 다른 종류의 문제를 다룹니다.
인출 문제
생각해볼 질문 (정답 없음)
- 인증서 체계는 결국 소수의 뿌리를 미리 믿기로 한 약속 위에 서 있습니다. 신뢰의 출발점을 없앨 수 없다면 그 출발점은 누가 어떤 자격으로 정해야 할까요.
이전: 네트워크와 인터넷 2강 · 다음: 네트워크와 인터넷 4강