HTTPS가 안전하다는 말은 누구나 알지만, 무엇이 어떻게 안전한지 설명하라고 하면 막히는 경우가 많습니다. 정보보안기사에서는 TLS 핸드셰이크 순서와 키 교환 방식, 전방 비밀성(PFS)이 필기와 실기 모두에서 반복되는 주제입니다. 이번 글에서는 TLS 1.2와 1.3을 비교하며 핵심만 짚어 보겠습니다.
TLS 핸드셰이크는 세 가지를 해결합니다. 상대가 진짜 서버인지 인증서로 확인하고(인증), 안전하게 공유할 세션키를 만들고(키 교환), 이후 데이터는 그 키로 암호화하고 무결성을 확인합니다. 시험에서는 이 흐름을 ClientHello, ServerHello, 인증서, 키 교환, Finished 순서로 묻는 문제가 자주 나옵니다.
전방 비밀성은 서버의 장기 개인키가 나중에 유출되더라도 과거에 오간 세션의 내용은 복호화할 수 없는 성질입니다. 세션마다 새로 만든 임시 키쌍으로 세션키를 합의하고 세션이 끝나면 버리기 때문에, 장기 개인키는 인증(서명)에만 쓰이고 세션키 계산에는 관여하지 않습니다.
왜 정적 RSA 키 교환이 문제인가: 공격자가 암호화된 트래픽을 계속 수집해 두었다가 훗날 서버 개인키를 손에 넣으면, 저장해 둔 모든 세션의 비밀값을 풀어 과거 통신을 한꺼번에 복호화할 수 있습니다. DHE나 ECDHE를 쓰면 이런 소급 복호화가 불가능해집니다.
1.2에서 PFS를 얻으려면 암호군 이름에 ECDHE 또는 DHE가 들어간 것을 선택해야 하고, 1.3에서는 모든 연결이 기본적으로 임시 키 교환을 쓰므로 따로 고민할 필요가 없습니다.
TLS 1.3의 0-RTT(early data)는 이전 연결에서 받은 정보를 이용해 첫 번째 메시지부터 데이터를 보내는 기능으로 속도는 빠르지만 재전송 공격에 취약할 수 있습니다. 그래서 결제처럼 한 번만 실행되어야 하는 요청에는 쓰지 않고, 조회처럼 여러 번 실행해도 안전한(멱등한) 요청에만 허용하도록 설계합니다. 또 세션 티켓을 암호화하는 서버의 장기 키가 유출되면 해당 티켓으로 재개된 세션의 보호가 약해질 수 있으므로 티켓 키를 주기적으로 교체하는 것이 권장됩니다.
서버가 어떤 버전과 키 교환을 쓰는지는 명령 한 줄로 볼 수 있습니다. 아래 명령은 직접 실행해 출력을 확인한 것입니다.
openssl s_client -connect 서버주소:443 -tls1_3 # 출력 예: New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 # Server Temp Key: X25519, 253 bits openssl s_client -connect 서버주소:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' # 출력 예: New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server Temp Key 줄이 보이면 임시 키로 키 교환을 했다는 뜻이므로 PFS가 적용된 연결입니다. 서버가 1.3을 지원하지 않으면 두 번째 명령처럼 1.2에서 ECDHE 암호군이 협상되는지 확인합니다.
이 글은 학습용 정리이며 실제 시험 범위와 다를 수 있습니다. 최신 출제 범위는 한국인터넷진흥원(KISA) 공식 공지를 확인하세요.
서울에서 주택분 재산세를 500만 원 넘게 내는 사람이 올해 처음 10만 명을 넘었습니다. 서울시 자료를…
기출문제를 풀어 보라는 조언은 맞지만, 기출 원문을 그대로 옮기는 것은 저작권과 정확성 면에서 적절하지 않습니다.…
한국은행 금융통화위원회가 내일(10월 22일) 기준금리를 결정합니다. 7월과 8월 두 번 연속 올린 뒤 처음 맞는…
전날 3.7%대 급락했던 코스피가 하루 만에 3%대 반등하며 5,700선을 되찾았습니다. 장중에는 매수 사이드카까지 발동됐고, 원·달러…
DSR 계산기연소득과 기존 대출을 반영한 DSR과 스트레스 금리 적용 전후의 최대 대출 가능액을 한 번에…
청약가점 계산기무주택 기간, 부양가족, 청약통장 가입기간을 입력하면 84점 만점 기준 가점과 다음 가점 상승일까지 보여줍니다.계산기…