HTTPS
HTTP의 한계
HTTP에는 3가지 문제점이 있다.
- 평문(암호화 하지 않은) 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
각각의 문제점을 자세히 알아보자.
1. 평문(암호화 하지 않은) 통신이기 때문에 도청이 가능하다.
HTTP 를 사용한 요청과 응답은 암호화 기능이 없기 때문에 평문으로 전송된다. 어떤 해결책이 있을까?
통신 암호화
SSL(Secure Socket Layer)나 TLS(Transport Layer Security)를 HTTP에 조합하여 통신 내용을 암호화 할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure)이라 부른다. TLS는 SSL이 표준화되면서 바뀐 이름이다. 동일하게 취급해도 괜찮다. 자세한 내용은 후의 HTTPS 에서 다룬다.
콘텐츠 암호화
콘텐츠 자체를 암호화 하여 암호회된 엔티티를 전송하는 방법이 있다. 이 방법을 위해서는 클라이언트 <-> 서버 간 암호화, 복호화 규약이 있어야한다. 평상시 브라우저와 웹 서버간 이용은 어렵고, 합의된 특정 서비스에서 사용된다.
2. 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
HTTP는 누구든지 요청을 보내면 응답하는 심플한 구조이다. 따라서 상대를 확인하지 않는 약점이 있다.
증명서(Certificate)
SSL은 암호화 뿐만 아니라 상태를 확인하는 수단으로 증명서를 제공하고 있다.
증명서는 신뢰할 수 있는 제3자 기관(CA: Certificate Authority)에 의해 발행된다. 통신 상대인 서버나 클라이언트가 가진 증명서를 확인하여 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.
3. 완전성을 증명할 수 없기 때문에 변조가 가능하다.
완전성이란 정보의 정확성을 가리킨다. 전송한 내용이 도중에 변조되었을 수도 있다. 이를 방지하기 위해 MD5, SHA-1 등의 해시 값을 확인하는 방법이 있고, 파일의 디지털 서명을 확인하는 방법이 있다. 후자의 방법으로 SSL을 사용한다.
위 세 가지 문제점을 각각 도청, 위장, 변조 문제점이라 한다.
이상 HTTP의 한계를 해결하기 위해 HTTPS가 등장한다. HTTPS는 HTTP의 도청, 위장, 변조 문제를 어떻게 해결했을까?
HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
HTTPS는 HTTP에 SSL(TLS)를 추가한 것이다. 이를 통해 앞서 말한 3가지 문제, 도청, 위장, 변조 문제를 해결한다. HTTPS를 사용하면 HTTP와 TCP/IP간의 새로운 계층인 SSL이 추가되어 보다 안전한 통신이 가능하다.
SSL(TLS)의 과정은 다음과 같다.
-
Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
브라우저는 웹 서버와 SSL 연결을 시도한다. 브라우저는 서버에게 서버의 식별을 요청한다. -
Server sends a copy of its SSL Certificate, including the server’s public key.
서버는 공개키와 함께 가지고 있는 SSL 인증의 복사본을 전송한다. -
Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.
브라우저는 받은 인증서를 브라우저가 저장한 인증기관에서 받은 리스트에서 유효성을 검증한다. 인증서가 검증에 통과한 경우 서버의 공개키를 이용해서 암호화한 대칭 세션 키를 만들어 서버로 전송한다. -
Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
서버는 받은 대칭 세션 키를 비밀키를 이용하여 복호화한다. 그리고 암호화된 세션 키를 응답하며 암호화된 세션을 시작한다. -
Server and Browser now encrypt all transmitted data with the session key.
서버와 브라우저는 암호화된 세션 키를 이용해 통신한다.
SSL의 특징
- 기본 포트는
443이다. - 통신 데이터가 암호화되어, 패킷이 탈취되는 사고가 발생해도 데이터를 지킬 수 있다.
- SSL 인증서를 통해 도메인의 신뢰성을 검증할 수 있다.
- 데이터 송/수신 과정에서 암/복호화가 발생하므로 속도가 느리다.
정리
정리하면, SSL이 제공하는 암호화, 인증서를 통해 도청, 위장, 변조 문제를 해결한다.
인증
FORM BASE 인증
Form Base 인증은 표준 인증 방식은 아니다. 클라이언트가 서버 상의 웹 어플리케이션에 자격 정보(Credential)를 전송하여 그 자격 정보의 검증 결과에 따라 인증을 하는 방식이다.
HTTP가 표준으로 제공하는 BASIC, DIGEST는 보안문제로 거의 사용되지 않고, SSL Client도 비용 문제로 널리 사용되기 힘들다. 따라서 대부분의 인증은 Form Base로 이루어진다.
인증 과정
서버 측의 웹 어플리케이션 등에 의해 클라이언트가 전송한 유저 ID와 패스워드가 서버에 등록된 것과 일치하는지 검증한다. HTTP는 무상태성(stateless) 프로토콜이기 때문에 세션 관리, 쿠키, 토큰 등의 방법을 이용해 상태 관리 기능을 구현한다.
SSL CLIENT 인증
SSL CLIENT 인증은 HTTPS의 클라이언트 인증서를 이용한 인증 방식이다. 사전에 등록된 클라이언트의 엑세스인지 확인할 수 있다. 단독으로 사용되지는 않고, Form Base 인증과 합쳐서 2-factor 인증의 하나로서 이용된다. 클라이언트 증명서의 비용이 비싸 널리 쓰기에는 무리다.
BASIC 인증
BASIC 인증에서는 BASE64라는 인코딩을 이용해 유저ID와 패스워드를 전송한다. 그러나 암호화는 아니기 때문에 누구나 복호화할 수 있어 거의 사용하지 않는다.
DIGEST 인증
Challenge - Response 방식으로 인증을 요구한다.
- 클라이언트는 서버에 인증 요구를 보낸다.
- 서버는 인증이 필요하다는 401 응답과 함께 챌린지 코드(nonce)를 보낸다.
- 클라이언트는 패스워드와 챌린지 코드(nonce)로 리스폰스 코드(response)를 계산하여 보낸다.
- 서버는 인증 성공시 200, 실패시 401을 응답한다.
DIGEST 인증은 패스워드의 도청을 방지하기 위한 보호 기능은 제공하지만 위장을 방지하는 기능을 제공하지는 않는다. 따라서 거의 사용되지 않는다.
참고
What is SSL?
[SSL] SSL이란?
우에노 센, 이병억 역, 그림으로 배우는 HTTP Network Basic, 영진 닷컴
