Https 정리
오타, 지적 환영입니다.
HTTPs
HTTPs는 (Hyper Text Transfer Protocol over Secure Socket Layer)의 약자이고 HTTP over TLS, HTTP over SSL, HTTP Secure로도 불린다.
소켓통신에서 일반 텍스트(평문)을 사용하는 대신에 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다.
기본 TCP/IP 포트는 443이다.
보호의 수준은 웹 브라우저에서의 구현 정확도, 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다.
HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법을 결합한 것이다.
HTTPs 나오게된 이유
HTTP의 문제점
HTTPs가 나오게 된 배경에는 HTTP의 한계를 보안하기 위함이 있다.
암호화되지 않은 HTTP 메시지를 TCP를 통해 전 세계에 보내는 대신해 HTTPS가 HTTP 메시지를 TCP로 보내기 전에 암호화하는 보안계층으로 보내버린다.
이 보안계층에서는 SSL과 이를 나름 최신화해서 업데이트한 TLS로 구현되어 있다. 우리는 이를 모두 의미하는 SSL을 말할 뿐이다.
HTTPS 스킴
현재 보안 HTTP는 선택적인데, 이를 웹 서버에 요청보낼때 알려줄 필요가 있다. 이것은 URL의 스킴을 통해 이루어진다.
1
2
http://~
https://~
이처럼 https라는 URL 스킴이 붙은것은 보안 HTTP를 사용한다고 웹 서버에 알리는 것이다.
기본적으로 http요청은 80번 포트에, https요청은 443번 포트에 연결을 하게 된다.
1
2
3
4
5
(http요청) port 80
client ---------------> Server
(https요청) port 443
client ---------------> Server
http는 요청을 보내면 일반 HTTP 명령을 보내게 된다.
https는 요청을 보내고, 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수들을 교환하며 핸드쉐이크를 하고 암호화된 HTTP 명령이 뒤를 잇는다.
SSL은 바이너리 프로토콜이기에 HTTP와는 다르다.(HTTP는 텍스트 프로토콜)
보안 전송
암호화 되지 않은 HTTP는 웹 서버의 80번 포트에 커넥션을 맺고 데이터를 주고 받은 후에 커넥션을 닫는다.
HTTPS는 이보다 좀 더 복잡하다.
- 443포트에 커넥션을 연결한다.
- 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다.
- 핸드셰이크가 완료되면 SSL 초기화가 완료된 후, 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있다.
- 이 메시지는 TCP/IP 계층으로 가기 전에 암호화가 된다.
- 이후 응답을 보내고, SSL을 닫고 커넥션을 닫는다.
SSL 핸드셰이크
핸드셰이크에서는 다음과 같은 일들이 벌어진다.
- 프로토콜 버전 번호 교환
- 양쪽이 알고 있는 암호 선택
- 양쪽의 신원을 인증
- 채널을 암호화하기 위한 임시 세션 키 생성
SSL은 통신을 시작하기 전에 상당한 양의 핸드셰이크 데이터를 주고 받는다.
- 3-way-handshake 이후, HTTPS라는걸 알게된 브라우저는 다음 정보를 웹 서버에 보낸다.
- 브라우저가 사용하는 SSL, TLS버전 정보
- 브라우저가 지원하는 암호화 방식 모음(cipher suite)
- 브라우저가 순간적으로 생성한 임의의 난수(숫자)
- 만약 SSL 핸드셰이크가 완료된 상태라면, 그때 생성된 세션 아이디
- 기타 정보
cipher suite란 암호화 알고리즘, 메시지 무결성 확인 알고리즘, 전달 대상 인증 등 이러한 방식들을 패키지로 모아놓은 것을 의미한다.
- 서버쪽에서 이를 응답하면서 다음 정보를 클라이언트에 제공한다
- 브라우저가 전달한 암호화 방식중에 서버가 지원하고 선택한 암호화 방식(cipher suite)
- 서버의 공캐키가 담긴 SSL 인증서
- 서버가 순간적으로 생성한 임의의 난수(숫자)
- 클라이언트는 위의 정보를 받고 내부적 검증절차를 거친다.
- 클라이언트 브라우저에 설치된 CA들의 정보와 CA가 만든 공개키를 통해 서버가 보낸 SSL인증서가 정말 CA가 만든 것인지를 확인.(복호화) 등록된 CA가 만든 인증서가 아니거나, 그런것처럼 꾸몄다면 이 과정에서 브라우저 경고를 보낸다.
웹 서버 인증서에 딸려온 웹 사이트 공캐키로 암호화하여 위 정보들을 서버로 전송. 이 부분은 밑에서 또 설명.
- 서버는 사이트의 비밀키로 브라우저가 보낸 정보들을 복호화한다.
- 복호화된 정보를 master secret값으로 저장. 이것을 사용하여 브라우저와 만들어진 연결에 대한 고유한 session key를 생성.
- 이 session key는 대칭키 암호화에 사용할 키이다. 이것으로 브라우저와 서버 사이에 주고받는 데이터를 암복화한다.
- SSL 핸드셰이크를 종료하고, HTTPS 통신 시작.
- 이 시점에서는 서버는 서로에게 공유된 sesssion key를 폐기한다. 브라우저에서 요청시에 세션ID만 알려주면 되기에 파기시켜도 된다.
서버 인증서
위에서 웹 서버 인증서에 딸려온 웹 사이트 공개키로 암호화 한다고 하였는데, 여기서 제공되는 인증서에 대해 알아보자.
SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 나르는 상호 인증을 지원한다.
오늘날 클라이언트 인증서는 흔히 쓰이지 않고, 직원들에게 보여주지 않을 정보를 기업 내에서 관리하는 등의 상황에서는 쓰이고 있다.
HTTPS는 항상 서버 인증서를 요구하는데, 잘 알려진 인증기관에 의해 서명된 서버 인증서는 민감한 데이터를 보낼때 그 서버를 얼마나 신뢰할 수 있는지 평가하는데 도움을 준다.
서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 등의 정보를 보여준다. 이러한 정보를 통해 클라이언트는 모든 정보가 믿을만한지 인증서를 검증할 수 있다.
사이트 인증서 검사
SSL 자체는 사용자에게 웹 서버 인증서를 검증하라고 시키지는 않지만, 최신 브라우저들은 대부분 인증서에 대한 기본적인 검사를 한다. 넷스케이프가 제안한 웹 서버 인증서 검사를 위한 한 알고리즘은 대부분 웹브라우저의 검사 기반의 기초를 구축했다.
위의 사진을 순서대로 따라가본다.
- 웹 서버는 인증기관에 자신의 사이트에 대한 정보를 인증기관에 공개키와 함께 보낸다.(비밀키는 본인이 소유하고 있음)
- CA에서 내부 검증을 통해 사이트 인증에 성공했으면 이를 인증기관 비밀키를 통해 암호화하여 인증서를 서버에 발급한다.
- 클라이언트에서 요청을 할 경우 SSL핸드셰이크를 수행한다.
- 그 과정중에 서버가 공개키를 담은 인증서를 보내는데, 이 인증서를 브라우저에 저장된 CA키를 가지고 그 기관에서 발급한 인증서가 맞는지 확인한다.
- 인증 되었다면 웹 서버가 보내준 공개키를 통해서 자신이 보낼 데이터를 암호화하고, 웹 서버는 자신의 비밀키를 통해 데이터를 복호화한다.
- 이후 cpu리소스 소모가 적은 대칭키 방식으로 데이터를 주고 받는다. 위의 통신 과정은 비대칭키 방식(공개키, 비밀키)을 사용한다. 이는 복잡한 수학적 원리로 이루어져 CPU 리소스 부담이 크다.
대칭키는 탈취당하면 모든 통신이 유출위험에 놓여있다. 때문에 웹 서버인증 과정에서 상대적으로 안전한 비대칭키 방식을 통해 얻은 서버의 공개키를 통해 대칭키 자체를 암호화해서 서버에 보내는 것이다.
참고
이것은 와이어샤크로 HTTP 패킷와 HTTPs패킷을 확인해본 사진이라고 한다.
위는 HTTPs, 밑은 HTTP메시지이다.
HTTPs는 암호화 되어있고, HTTP 패킷은 평문으로 보이는걸 확인할 수 있다.
Reference
- HTTP완벽가이드 서적
- https://brunch.co.kr/@sangjinkang/37 인증 과정
- https://brunch.co.kr/@sangjinkang/38 SSL 핸드셰이크
- https://ko.wikipedia.org/wiki/HTTPS 위키백과
- https://yunzema.tistory.com/358 패킷 까보기