HTTPS payload 평문? 암호화?
💁 HTTPS 사용하더라도 비밀번호는 암호화 후 전송해야하는 거 아니야?
예전에 개발자 단톡방에서 위와 같은 주제가 논의된 적이 있었습니다.
위와 같은 질문이 있을 때 필자는 HTTPS를 사용하고 있다면 이미 TLS를 통해서 비대칭키 암호화를 수행하기 때문에 프론트엔드단에서 암호화가 필요없다고 생각했습니다.
실제 서비스들은 어떻게 하고 있나?
이러한 궁금증을 해결하기 위해서 실제 서비스들은 어떻게 하고 있는지 조사해봤습니다. 국내 주요 사이트인 11번가, 네이버 등은 비밀번호를 평문이 아닌 암호화해서 전송하는 방식을 사용하고 있었습니다.
또한, 이전 블로그 글들을 보면 페이스북이 평문으로 전송한다고 기재된 글들이 많아서 직접 살펴보게 됐습니다. 그래서 2025년 기준으로 찾아본 결과 페이스북도 암호화해서 전송하는 것을 확인했습니다.
아래 사진에서 encpass (encript password)를 통해서 비밀번호를 암호화하고 있는 것을 확인할 수 있죠.
반면, 비밀번호를 평문으로 전송하는 서비스로는 AWS, 쿠팡, 트위터, Github, 링크드인을 찾아볼 수 있었습니다. 하지만 이러한 서비스 중에서 일부는 2FA(2단계 인증), MFA(다단계 인증), 세션 등 추가적인 보안 조치가 되어있는 것을 확인할 수 있습니다.
- 평문 전송 : AWS, 쿠팡, 트위터, Github, 링크드인 ... (그렇지만 추가적인 보안조치)
- 암호화 전송 : 11번가, 네이버, 페이스북 ...
데이터 전송 방식과 암호화 사례
대부분의 웹 사이트들은 HTTPS를 사용해서 보안을 신뢰하고 있지만, 일부 기업 및 사이트들은 HTTPS에 더해 추가적인 암호화 후 전송하는 보안 방식을 사용하고 있는 것을 확인할 수 있었습니다. 이어지는 내용에서는 기본적인 전송방식, 클라이언트 측 암호화, 그리고 종단간 암호화하는 사례에 대해서 살펴보겠습니다.
1. 평문 전송 후 서버에서 해싱, 암호화
보통 기본적인 비밀번호 전송 방식으로는 HTTPS에서 평문(plain text)으로 전송한 후 서버에서 이를 해싱 및 암호화하여 DB에 저장하는 방식을 말합니다.
한계점
이 방식의 한계점으로는 재전송 공격(Replay Attack)에 취약하다는 점이 있습니다. 공격자가 HTTPS 요청을 캡쳐해서 재전송할 시 정상적인 로그인 시도로 인식할 수 있기 때문입니다.
2. 클라이언트 측에서 암호화 후 전송하는 경우
1. 중간자(MITM) 공격 시 재전송 공격(Replay Attack) 방어
중간자(MITM: man in the middle attack) 공격이란?
: 사용자와 사용자 사이에서 중간자가 칩임하여 통신을 도청하거나 패킷을 가로채서 조작하는 공격 기법.
- 공격 유형 : SSL 스니핑, SSL 스트리핑, 이메일 하이재킹, 와이파이 도청 등
만약 HTTPS 환경에서 해커가 특정 공격 기법을 통해 MITM 공격에 성공했을 때
사용자와 서버 사이의 데이터를 가로챘어도 만약 암호화된 데이터라면 해당 데이터를 활용할 수 없게 됩니다.
- 단, Nonce(일회성 난수 토큰) 방식 등을 통해 구현해야합니다.
공격자가 요청을 중간에서 가로채 요청을 재전송하더라도 Nonce 방식으로 해당 토큰은 1번만 사용하므로 공격에 실패하기 때문입니다.
이렇게 구현하지 않는다면 공격자가 암호화된 요청을 그대로 재전송할 시 정상적인 요청으로 받아들여져 암호화값 자체를 악용하여 활용할 수 있게 되버립니다.
2. 추가적인 보안 요구사항이 있는 경우
금융, 의료, 공공기관, 정부관련 등에서 데이터 자체가 유출되어서 활용되면 안되는 경우 보안 강화를 위해서 활용될 수 있습니다.
3. E2EE(End-to-End Encryption)
엔드 투 엔드 암호화(E2EE)는 일명 단 대 단 암호화, 종단간 암호화라고 불립니다.
발신자 - 수신자는 각 종단의 엔드를 뜻합니다. 예를 들면 페이스북에서 메시지를 보내는 사람과 받는 사람만 메시지를 읽을 수 있고, 페이스북은 읽을 수 없습니다.
데이터는 오로지 주고받는 당사자만 열람 가능한 방식을 말합니다.
발신자(열람 가능) - 페이스북 서버(열람 불가능) - 수신자(열람 가능)
메시지 발신자와 수신자만 메시지 해독을 해서 조회를 하고 서버에서는 해독이 불가하므로 메시지 원본을 볼 수가 없습니다. 복호화 키를 Server가 아닌 수신자 장치에 저장합니다. 따라서 서버조차 복호화할 수 없기 때문에 해킹에 대한 위험이 줄어듭니다.
특징
- Application Layer에서 구현됨
- 서버에 복호화 키가 없으므로 데이터 유출 시에도 보호됨
- 인스턴스 메시지(단톡 채팅방, 비밀 채팅), 민감한 개인정보, Zoom 음성대화 등
- 프라이버시 강화에 초점
범죄에 악용될 수 있는 한계점
한계점으로는 해킹에 대해서는 안전하지만 메시지 복구가 어렵고 범죄행위에 악용될 수 있다는 점이 있습니다. 22년 BBC 기사를 보면 영국정부, 아동자선단체는 아동 성범죄에 악용될 수 있는 측면 때문에 반대를 하고 있는 상황이었기 때문에 E2EE가 연기되었고 그 다음해인 23년 말에 페이스북에서 E2EE를 도입한 것을 확인할 수 있었습니다. 레딧에서 E2EE로 변경된 방식에 대해서 불평을 가진 사람들도 볼 수 있었습니다.
통신 보안을 위한 방식: mTLS(Mutual TLS)
mTLS는 클라이언트측 인증서 전달해서 신원 증명 단계가 추가된 방식입니다. 기존 TLS에서 서버의 신원 증명하는 방식에서 더 나아가 클라이언트단도 인증하는 방식입니다. 서버와 클라이언트 간 서로의 신원을 확인해야 할 때 사용합니다. 예를 들어 B2B 기업간 통신할 때 사용됩니다.
E2EE가 사용자 간 프라이버시 보호에 목적을 뒀다면, mTLS는 클라이언트-서버 간 신원 보장에 목적을 둔 점에서 차이가 있습니다.
특징
- Transport Layer에서 동작됨
- 서버나 DB에서 데이터 조회 가능
- 양쪽에서 상호 신원을 확인함으로써 통신 보안에 초점 맞춘다.
동작 과정
- 클라이언트와 서버 연결
- 서버가 클라이언트에 TLS 인증서 제시
- 클라이언트는 서버 인증서 확인 후, 자신 인증서를 서버에 전달
- 서버는 클라이언트 인증서 확인 후 접근 허용
- 클라이언트는 공개키로 대칭키 암호화해서 서버에 전송
- 서버는 개인키로 복호화해서 대칭키 획득
- 서버는 대칭키로 암호화된 데이터 전송
마치며
HTTPS는 기본적인 보안을 제공해주는 수단입니다. 하지만 특정 보안 요구사항이 있다거나, 특정 해킹 공격에 대비해서 추가적인 암호화를 수행하는 예시들을 살펴보았습니다. 다만 예시를 들은 모든 것을 암호화 방식이 필수라는 것이 아니라 서비스 요구사항의 필요에 따라서 적절한 보안 기법을 도입하는 것이 바람직해 보입니다. 그리고 혹시 틀린 정보가 있을 수 있으니 이에 대해서는 댓글로 정보를 남겨주시면 감사하겠습니다.
