[Web] HTTP vs. HTTPS

HTTP와 HTTPS의 차이

HTTP는 HyperText Transfer Protocol로, 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜이다. 예를 들어, 클라이언트인 웹 브라우저가 HTTP를 통해서 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. TCP/IP 모델에서 응용 계층에 해당하는 프로토콜이다.

 

웹 서핑을 할 때 서버에서 웹 브라우저로 데이터를 전송해주는 용도로 가장 많이 사용된다.

 

 

HTTPS는 HTTP + over Secure Socket Layer의 약자이다. 기존의 HTTP 프로토콜의 문제점은 서버에서 브라우저로 전송되는 정보가 암호화되지 않는다는 점이다. 즉, 데이터가 쉽게 도난당할 수 있다는 것이다. HTTPS 프로토콜은 기존의 HTTP 에 SSL(Secure Socket Layer)을 사용함으로써 이 문제를 해결했다.

 

HTTPS는 HTTP 통신하는 소켓 부분을 SSL이나 TLS(Transport Layer Security) 라는 프로토콜로 대체한 프로토콜이다. HTTP는 원래 TCP 와 직접 통신했지만, HTTPS에서는 HTTP는 SSL과 통신하고, SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

 

HTTPS의 SSL에서는 대칭키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 대칭키를 공개키 암호화 방식으로 교환한 다음에 다음으로부터의 통신은 대칭키 암호를 사용하는 방식이다.

 

* 대칭키 & 공개키

대칭키(Symmentric Key, 공통키) 알고리즘

암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘

동일한 키를 주고 받기 때문에, 매우 빠르다는 장점이 있다.

하지만, 대칭키 전달 과정에서 해킹 위험에 노출될 수 있다.

공개키(Public Key) 알고리즘

암호화와 복호화에 사용하는 암호키를 분리한 알고리즘

자신이 가지고 있는 고유한 암호키(개인키/비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개한다.
/* 공개키로 암호화, 공개키와 매칭되는 개인키로 복호화 */
ㄴ 꼭 이런건 아니다!!

공개키 암호화 방식 진행 과정

1. A가 웹 상에 공개된 B의 공개키를 이용해 평문을 암호화하여 B에게 보낸다.
2. B는 A가 보낸 암호화된 평문을 자신의 개인키로 복호화한 후, A의 공개키로 응답을 암호화하여 A에게 보낸다.
3. A는 자신의 개인키로 암호화된 응답문을 복호화한다.

이는 대칭키의 단점을 완벽하게 해결했지만, 암호화하는 키와 복호화하는 키가 서로 다르기 때문에 암호화, 복호화가 매우 복잡하다.

 

 

대칭키 + 공개키 -> SSL 탄생의 시초

1. A 가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보낸다.
2. B는 암호문을 받고, 자신의 비밀키로 복호화한다.
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화해서 A에게 보낸다.
4. A는 자신의 대칭키로 암호문을 복호화한다.
5. 앞으로 이 대칭키로 암호화를 통신한다.

즉, 대칭키를 주고 받을 때만 공개키 암호화 방식을 사용하고, 이후에는 계속 대칭키 암호화 방식으로 통신한다.

 

 

[HTTPS 통신 흐름]

 

[서버 - CA]

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 생성한다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
   • CA(Certificate Authority): 공개키를 저장해주는 신뢰성이 검증된 민간 기업
3. 계약된 CA 기업은 해당 기업의 이름, A 서버의 공개키, 공개키 암호화 방법, 유효기간 등을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
4. A 서버는 암호화된 인증서를 갖게 되었다. 이제 A 서버는 발급받은 인증서와 자신의 개인키를 서버에 설정하여 HTTPS 통신을 할 수 있다.

• 클라이언트, 즉 웹 브라우저에는 여러 인증 기관의 공개키를 포함한 인증서가 이미 설치되어 있다. 그래서 웹 서버와 통신 시 인증 기관의 개인키로 서명된 인증서를 받았을 때 이미 설치되어 있는 인증기관의 공개키로 복호화가 가능한 것이다.

 

 

[클라이언트 접속]

5. 클라이언트가 웹 브라우저로 사이트에 접속하면 A 서버는 인증서를 브라우저에게 보낸다. 이 인증서에는 인증기관의 개인키로 암호화된 사이트의 정보와 A 서버의 공개키가 들어있다.
6. 웹 브라우저는 이미 가지고 있는 인증기관의 공개키로 A 서버에서 받은 인증서를 복호화해서 확인한다.
7. 웹 브라우저는 실제 데이터의 암호화에 사용될 대칭키를 생성하고, 인증서에서 꺼낸 A 서버의 공개키로 암호화해서 A 서버로 보낸다.
8. A 서버는 자신이 가지고 있는 개인키로 웹 브라우저가 보내온 대칭키를 복호화해서 얻는다. 이제 이 대칭키로 데이터를 암호화해서 주고 받게 된다.

* 신뢰받는 CA 기업이 아닌 자체 인증서를 발급한 경우 등 HTTPS도 무조건 안전한 것은 아니다. 이 때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트 와 같은 알림으로 주의받게 된다.

 

 

[모든 웹 페이지에서 HTTPS를 사용하지 않는 이유?]

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하다. 통신할 때마다 암호화를 하면 많은 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 줄어들게 된다. 그렇기 때문에 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다.

 

cf) HTTP 2.0이 발전하면서 HTTPS 가 HTTP보다 빠르다고 한다. 요기서

 

 

 

 

 

 

Reference

https://offbyone.tistory.com/274

https://jeong-pro.tistory.com/89

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/HTTP%20%26%20HTTPS.md

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network#http%EC%99%80-https