HTTPS

보안상 문제가 발생하는 HTTP

HTTP에는 많은 장점들이 있지만 아래와 같은 보안상 문제가 발생할 수 있기 때문에 현대 웹에서는 HTTPS를 통해 해결하고 있다.

평문 통신(메시지 탈취 가능)

TCP/IP 특성상 중간에 누군가가 패킷을 가로채면 내용을 확인할 수 있으며, HTTP는 암호화가 되어 있지 않기 때문에 패킷을 가로채면 내용을 확인할 수 있다. 이를 해결하기 위해 암호화를 사용하는 방법이 있다.

• 통신 암호화

통신을 암호화 하는 방법으로 SSL(Secure Socket Layer)와 TLS(Transport Layer Security)를 사용해 암호화를 할 수 있다.

• 컨텐츠 암호화

통신을 통해 전달하고 있는 메시지를 암호화 하는 방법으로, 암호화된 메시지를 전달하고 받는다. 클라이언트/서버 모두 암호화/복호화 과정을 거쳐야 하기 때문에 암호화/복호화 과정이 추가되어 성능이 떨어지는 단점이 있으며, 주로 웹 서비스에서 사용할 수 있다.

통신 상대 확인 불가능(위장 가능)

HTTP는 클라이언트가 서버에게 요청을 보낼 때, 서버가 해당 클라이언트가 맞는지 확인하지 않기 때문에 위장이 가능하다. 이를 해결하기 위해 제 3자가 발급하는 인증서를 사용해 서로를 확인하여 위장을 방지할 수 있다.(현재 위조하는 것은 기술적으로 어렵다.)

완전성 확인 불가능(변조 가능)

HTTP는 메시지가 중간에 변조되지 않았는지 확인할 수 없기 때문에 변조가 가능하다.(요청이나 응답을 가로채서 변조하는 공격 = 중간자 공격) 이를 방지하기 위한 방법이 디지털 서명이라는 방법이 존재하나, 이 방법 하나만으로는 완벽한 보안을 보장할 수 없다.

HTTP + SSL = HTTPS

HTTP에 SSL 혹은 TLS를 적용한 것으로, HTTP에 SSL이나 TLS를 적용하면 위에서 언급 된 보안상 발생하는 문제를 해결할 수 있다. 새로운 애플리케이션 계층의 프로토콜은 아니며, HTTP 통신 소켓 부분을 SSL이나 TLS로 대체한 것이다.

• SSL(Secure Socket Layer) : 1994년에 공개된 암호화 프로토콜

• TLS(Transport Layer Security) : SSL의 후속 버전으로 현재 주로 사용되는 프로토콜

TLS와 SSL는 매우 비슷하기 때문에 SSL이라고 통칭하여 사용하는 경우가 많다.

HTTP	HTTPS
HTTP - 애플리케이션 계층	HTTP - 애플리케이션 계층
-	SSL or TLS - 보안 계층
TCP - 전송 계층	TCP - 전송 계층
IP - 네트워크 계층	IP - 네트워크 계층
네트워크 인터페이스 - 데이터 링크 계층	네트워크 인터페이스 - 데이터 링크 계층

인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 내부에서 처리되기 때문에, 웹 클라이언트나 서버가 별도로 크게 처리할 부분은 없다. 결국 HTTPS는 HTTP 프로토콜에 대칭/비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것으로 네트워크 상에서 가장 널리 사용되는 보안 프로토콜이다.

SSL(HTTPS)에 이용되는 디지털 암호학 기초

HTTP / HTTPS 트랜잭션 비교

URL 프로토콜 스키마에 따라 HTTP/HTTPS로 통신하게 되며, 각각 아래와 같은 트랜잭션을 거치게 된다.

암호화되지 않은 HTTP 트랜잭션	암호화된 HTTPS 트랜잭션
서버의 80포트로 TCP 커넥션 수립	서버의 443포트로 TCP 커넥션 수립
-	SSL 보안 매개변수 핸드셰이크
TCP를 통해 보내진 HTTP 요청	SSL을 통해 보내진 HTTP 요청 / TCP를 통해 보내진 암호화된 요청
TCP를 통해 보내진 HTTP 응답	SSL을 통해 보내진 HTTP 응답 / TCP를 통해 보내진 암호화된 응답
-	SSL 닫힘 통지
TCP 커넥션 닫힘	TCP 커넥션 닫힘

SSL Handshake

암호화된 HTTP 메시지를 보내기 위해서는 클라이언트와 서버가 서로 암호화에 필요한 정보를 교환해야하는데, 이를 SSL Handshake라고 한다. 서버-클라이언트 최초 연결 시 비대칭키 암호화 방식(최초 연결)을 사용하여 서로의 신원을 확인한 뒤 세션 키를 생성하고, 그 이후에는 생성 된 세션 키를 통해 대칭키 암호화 방식을 사용하여 데이터를 주고받는다.

1. 클라이언트 헬로 (Client Hello)

   • 클라이언트는 서버에 “Client Hello” 메시지를 보내어 통신을 시작

   • 클라이언트가 사용 가능한 암호화 알고리즘 전송

2. 서버 헬로 (Server Hello)

   • 서버는 클라이언트의 헬로 메시지에 응답하여 “Server Hello” 메시지 전송

   • 서버가 선택한 알고리즘을 전송

3. 인증 (Certificate)

   • 서버는 SSL 디지털 인증서를 클라이언트에게 전송(해당 인증서는 서버의 신원을 확인하는 데 사용)

   • 클라이언트는 서버가 보낸 CA(Certificate Authority, 인증 기관)의 개인키로 암호화된 SSL 인증서를 공개된 CA의 공개키를 사용하여 복호화

   • 또한 클라이언트는 데이터 암호화에 사용할 대칭키(비밀키)를 생성한 후 SSL 인증서 내부에 들어있던 서버가 발행한 공개키를 이용해 암호화하여 서버에게 전송

4. 서버 키 교환 (Server Key Exchange)

   • 서버의 공개키가 SSL 내부에 없었을 경우 서버가 직접 전달하는 과정

   • 이미 SSL 내부에 있었다면 생략

5. Server Hello Done

   • 핸드쉐이크 초기 단계 완료

6. 클라이언트 키 교환 (Client Key Exchange)

   • 클라이언트는 세션 키를 생성하기 위한 정보를 서버에 보냅니다. 이는 서버의 공개 키를 사용하여 암호화되어 전송됩니다.

   • 실제로 데이터를 암호화할 대칭키를 클라이언트가 생성하여 SSL 인증서 내부에서 추출한 서버의 공개키를 이용해 암호화한 후 서버에게 전달

7. Client ChangeChipherSpec / Finished

   • 클라이언트에서 “ChangeChipherSpec” 메시지를 보내 암호화된 통신 시작을 알림

   • 이후 “Finished” 메시지를 보내 핸드쉐이크 과정 완료 알림

8. Server ChangeChipherSpec / Finished

   • 서버도 “ChangeChipherSpec” 메시지를 보내 암호화된 통신을 시작함을 알림

   • 이후 “Finished” 메시지를 보내 핸드쉐이크 과정 완료 알림

사이트 인증서 검사

SSL 자체는 사용자에게 인증서 검증 요구를 하지 않지만, 최신 웹브라우저 대부분이 인증서에 대해 기본적인 검사를 한 뒤 높은 수준의 검사를 하는 방법을 사용자에게 제공한다. 넷스케이프에서는 웹 서버 인증서 검사를 위한 알고리즘을 만들어 기초를 구축했으며, 수행 단계에서 아래의 검사를 수행한다.

• 날짜 검사: 인증서의 시작 및 종료일 검사

• 서명자 신뢰도 검사: 브라우저에 내장된 인증서 발급자 목록과 인증서 발급자의 이름을 비교(신뢰할 수 있는 발급자인지 검사)

• 서명 검사: 서명기관의 공개키를 서명에 적용하여 체크섬과 비교하여 무결성 검사

• 사이트 신원 검사: 인증서 복사 혹은 트래픽 중간자 공격을 막기 위해 인증서의 도메인 이름과 통신 중인 서버 호스트의 도메인이 일치하는지 검사

참고자료

• HTTP 완벽 가이드