HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 말합니다.
1. SSL/TLS (Secure Socket Layer, Transport Layer Security Protocol)
- SSL은 1 버전부터 시작해서 2, 3 그리고 TLS 1.0, TLS 1.3까지 버전이 업그레이드되며 마지막으로 TLS로 명칭이 변경되었지만, 보통 SSL/TLS로 불립니다.
- SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜입니다. 클라이언트와 서버가 통신할 때 이 프로토콜을 통해서 제3자가 메시지에 접근할 수 없도록 해줍니다. (인터셉터 방지)
- SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용됩니다.
보안 세션
보안이 시작되고 끝나는 동안 유지되는 세션을 의미합니다. SSL/TLS는 Handshake를 통해서 보안 세션을 생성하고, 이를 기반으로 상태 정보 등을 공유합니다.
2. HTTPS를 사용하는 이유
- HTTP 프로토콜은 암호화되지 않은 평문의 데이터를 전송하는 프로토콜이기 때문에 내가 서버로 보낸 정보(id, password)를 중간에 누군가 훔쳐볼 수 있습니다.
- HTTPS를 사용하게 되면 클라이언트와 서버만 알고 있는 형태로 암호화되어 데이터를 전송하기 때문에 중간에 훔쳐보더라도 어떤 정보인지 알아내기 힘듭니다.
- 그리고 접속한 사이트가 신뢰할 수 있는 곳인지를 사용자에게 알려줍니다.
- 즉 HTTP에서 보안적인 부분까지 포함된 것이 HTTPS이기 때문에 대부분의 서비스에서는 현재 HTTPS 프로토콜을 사용합니다.
3. 대칭키와 비대칭키
- HTTPS의 보안 방식을 알아보기 위해서는 대칭키와 비대칭키에 대해서 알고 있어야 합니다.
(1) 대칭키
- 서버와 클라이언트 양쪽이 모두 동일한 키로 데이터를 복호화하는 방법을 말합니다.
- 데이터를 전송할 때는 키를 가지고 데이터를 암호화해서 보내고, 받는 쪽에서 동일한 키를 가지고 데이터를 복호화해서 사용합니다.
- 하지만 서버와 클라이언트 모두 동일한 키를 가지기 위해서는 한 번은 키에 대한 정보도 보내줘야 하는데, 키를 전송하는 과정에서 누군가에게 키가 노출된다면 데이터를 암호화하는 이유가 사라지게 된다는 한계가 있습니다.
- 그래서 나온 방법이 비대칭키입니다.
(2) 비대칭키 (공개키)
- 개인키와 공개키를 한 쌍으로 사용하는 암호화/복호화 방법입니다.
- 서버와 클라이언트가 있으면 서버에서는 개인키(나만 알고 있는 키)를 가지고 있고, 클라이언트들은 공개키(모두가 볼 수 있는 키)를 가질 수 있습니다.
- 내 개인키로 암호화한 데이터는 같은 쌍의 공개키로만 복호화를 할 수 있고, 반대로 공개키로 암호화한 데이터는 같은 쌍의 개인키로만 복호화를 할 수 있습니다.
- 이 방법을 사용하면 대칭키의 한계를 해결할 수 있습니다. 클라이언트가 데이터(id, password)를 공개키로 암호화해서 보내더라도 훔쳐보는 사람이 같은 쌍의 개인키를 가지고 있지 않으면 절대 내용을 볼 수 없습니다.
- 반대로 신뢰할 수 있는 서버에서 보내준 사이트라는 것을 구분할 수 있는 원리는 다음과 같습니다.
(3) 클라이언트와 서버의 HTTPS를 통한 데이터 전달
(3.1) 클라이언트는 처음에 서버를 신뢰하지 못하기 때문에 둘 사이에 Handshake를 거칩니다.
- 클라이언트가 랜덤 데이터를 생성해서 서버로 보냅니다.
- 서버는 클라이언트에게 전달받은 데이터에 추가로 서버가 랜덤으로 생성한 어떤 데이터와 해당 서버가 발급받은 인증서를 실어서 다시 클라이언트에게 보냅니다.
(3.2) 클라이언트는 서버에서 받은 데이터(인증서)를 비대칭키 방식을 사용해서 복호화합니다.
- 클라이언트는 전달받은 데이터(인증서)를 브라우저에 내장되어 있는 CA를 통해서 정보를 확인하게 됩니다.
- CA의 인증을 받은 인증서는 CA의 개인키로 암호화가 되어 있습니다. 즉, 클라이언트는 서버 쪽에서 보내준 인증서가 브라우저에 내장된 CA가 인증한 신뢰할 수 있는 인증서인지를 확인할 수 있습니다.
- 클라이언트는 브라우저에 저장된 CA의 공개키를 가지고 해당 인증서를 복호화해 볼 수 있습니다. 복호화가 된다면 신뢰할 수 있는 서버가 보낸 데이터이고, CA 리스트에 있는 모든 공개키로 인증서가 복호화되지 않는다면 신뢰할 수 없는 서버에서 보낸 데이터입니다.
- 신뢰할 수 있는 서버에서 보낸 인증서를 CA의 공개키로 복호화해 보면 그 안에는 해당 서버의 공개키가 포함되어 있습니다.
(3.3) 클라이언트와 서버는 대칭키 방식으로 데이터를 주고받습니다.
- 주고받는 다량의 데이터들을 계속 비대칭키 방식으로 암호화, 복호화하는 것은 컴퓨터에 큰 무리가 될 수 있는 작업입니다.
- 그래서 1번 과정인 Handshake 과정에서 주고받은 클라이언트가 생성한 랜덤한 데이터와 서버가 생성한 랜덤한 데이터를 가지고 클라이언트는 임시키를 만들어냅니다.
- 이렇게 만들어낸 임시키를 2번 과정에서 얻어낸 해당 서버의 공개키를 사용해서 암호화하여 서버로 보낸 후 양쪽(클라이언트, 서버)에서 일련의 과정을 거쳐서 둘만 가지고 있는 동일한 대칭키를 만들어냅니다.
- 이때부터는 이제 이 대칭키를 사용해서 데이터를 암호화하고 복호화해서 전송해도 제3자가 이 내용을 알아볼 수 있는 방법은 없습니다.
CA (Certificate Authorites)
공인된 민간 인증 기관들을 말합니다. CA는 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있습니다. 클라이언트가 사용하는 크롬, 사파리, 엣지 등 브라우저에는 이 CA들의 목록이 내장되어 있습니다. 대표적인 CA는 Comodo, GoDaddy, GlobalSign, 아마존이 있습니다.
4. HTTP/3
- TCP 위에서 돌아가는 HTTP/2와는 다르게 HTTP/3는 UDP 기반의 QUIC(Quick UDP Internet Connection) 프로토콜을 사용합니다.
- HTTP/2에서 HTTP/1.1의 문제점을 개선하기 위해 만들었던 멀티플렉싱을 HTTP/3에서 모두 가지고 있습니다.
- QUIC는 TCP를 사용하지 않기 때문에 통신이 시작될 때 진행하는 3-way-handshake 과정을 거치지 않아도 되기 때문에 초기 연결 설정 시에 지연 시간이 감소되는 장점을 가지고 있습니다.
- QUIC는 첫 연결 설정에서 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 통신을 시작할 수 있습니다.
- 추가로 QUIC는 순방향 오류 수정(Forward Error Correction) 메커니즘을 가지고 있기 때문에 전송한 패킷이 손실되면 수신 측에서 에러를 검출하여 수정하는 방식을 사용해서 패킷 손실률을 많이 낮추고 있습니다. (UDP의 단점 보완)
- QUIC에는 TLS 1.3 기반의 내장 암호화 프로토콜이 포함되어 있어서 보안 통신을 제공하고, 제3자가 인터넷 트래픽을 가로채고 조작하는 것을 어렵게 만들어줍니다.
💡 나올 수 있는 면접 질문
- 암호화방식 중 대칭키 방식과 비대칭키 방식에 대해서 설명해 보세요.
- HTTP 통신 방식의 문제점에 대해서 설명해 보세요.
'📘 Computer Science > 네트워크' 카테고리의 다른 글
| [네트워크] PDU (Protocol Data Unit) (0) | 2023.06.03 |
|---|---|
| [네트워크] 네트워크 프로토콜 표준화 (0) | 2023.06.03 |
