HTTP & HTTPS

HTTP, Hyper Text Transfer Protocol

HTTP는 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다.

Application Level의 프로토콜로, TCP/IP 위에서 작동하며 80번 포트를 사용한다.

구성

HTTP 보안 취약점

HTTP는 암호화되지 않은 평문 데이터를 전송하므로, 보안에 있어서 취약점이 존재한다.

 

취약점	HTTP	HTTPS
도청	평문으로 통신하기 때문에 도청 가능	통신 자체를 암호화
위장	통신의 상대를 확인하지 않기 때문에 위장된 상대와 통신할 수 있다.	CA 인증서를 통해 인증된 상대와 통신이 가능하다.
변조	완전성을 보장하지 않기 떄문에 변조가 가능하다.	메시지 인증 코드(MAC), 전자 서명 등을 통해 변조를 방지한다.

 

 

---

 

HTTPS, Hyper Text Transfer Protocol Secure

인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해, 클라이언트와 서버가 자원을 주고 받을 떄 쓰는 통신 규약이다. 즉, HTTP에 데이터 암호화가 추가된 프로토콜로 443번 포트를 사용한다.

HTTPS의 암호화 방식

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 둘 다 사용한다. 만약 여기에 대해 자세히 보고 싶으면 다음 링크를 참조하길 바란다.

 

대칭키 & 비대칭키

 

HTTPS 통신 흐름

사전 키워드

• CA, Certificate Authority : 공개키를 저장해주는 신뢰성이 검증된 민간 기업

[HTTPS의 발급 과정]

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
3. 계약 완료된 CA 기업은 해당 기업의 이름, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
4. A 서버는 암호화된 자신의 인증서를 갖게 되었다.

[HTTPS의 동작 과정]

1. A 서버는 A 서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
   1. 클라이언트가 main.html 파일을 달라고 A 서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA 기업이 A 서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 클라이언트가 받게 된다.
2. 브라우저는 (이미 널리 알려져 있는) CA의 공개키로 인증서를 해독하여 A 서버의 공개키를 얻는다.
3. 클라이언트가 A 서버와 HandShaking 과정에서 주고받은 난수를 조합하여, pre-master-secret-key(대칭키)를 생성한 뒤, A 서버의 공개키로 해당 대칭키를 암호화하여 서버로 보낸다.
4. A 서버는 암호화된 대칭키를 자신의 개인키로 복호화하여 클라이언트와 동일한 대칭키를 얻는다.
5. 클라이언트와 서버는 각각 pre-master-secret-key를 master-secret-key로 만든다.
6. master-secret-key를 통해 session-key를 생성하고, 이를 이용하여 대칭키 방식으로 통신한다.
7. 각 통신이 종료될 때마다 session-key를 파기한다.

덜 안전한 HTTPS?

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

 

---

 

[Web] HTTP와 HTTPS의 개념 및 차이점