한 걸음씩 확실하게

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자가 인터넷 트래픽을 가로채고 조작하는 것을 어렵게 만들어줍니다.

💡 나올 수 있는 면접 질문

1. 암호화방식 중 대칭키 방식과 비대칭키 방식에 대해서 설명해 보세요.
2. HTTP 통신 방식의 문제점에 대해서 설명해 보세요.

1. PDU (Protocol Data Unit)이란?

• 네트워크의 계층과 계층 사이에 데이터가 전달될 때 한 덩어리의 단위를 PDU라고 합니다.
• PDU는 헤더와 페이로드로 구성되어 있고, 계층마다 부르는 명칭이 다릅니다.

(1) 헤더 (Header)

• 각 계층마다 필요한 정보 및 기능이 담겨있습니다.
• 제어 관련 정보들이 포함되어 있습니다.
• (송신) 상위 계층에서 전달된 PDU에 자신의 계층에서 만든 헤더를 추가해서 하위 계층으로 전달합니다.
• (수신) 각 층에서 생성한 헤더 정보는 각 층에서 해결합니다.

(2) 페이로드 (Payload)

• 송신 측에서 보내고자 하는 실제 데이터를 의미합니다.
• 택배를 예로 들면 박스, 송장, 포장지 등은 페이로드에 속하지 않고, 받기로 한 택배물이 페이로드라고 생각하면 됩니다.

1. 네트워크 프로토콜이란?

• 다른 장치들끼리 데이터를 주고받기 위해 설정된 공통된 인터페이스를 말합니다.
• 쉽게 생각해 보면 장치와 장치 사이에 데이터 통신을 해야 하는데, 미리 정해놓은 어떤 규약(약속)에 따라서 통신을 하게 됩니다. 이때 이 규약(약속)을 네트워크 프로토콜이라고 합니다.

2. 프로토콜의 표준화가 필요한 이유?

• 모든 송신자와 모든 수신자가 표준화된 프로토콜을 지키기만 한다면 서로 통신이 가능하도록 해줍니다.
• 하지만 프로토콜이 표준화되어 있지 않다면, 특정 송신자는 자신의 프로토콜과 일치한 특정 수신자에게만 데이터를 송신할 수 있게 됩니다.

3. 프로토콜의 종류

• 많이 들어본 프로토콜 위주로 정리해보면 TCP, IP, UDP, HTTP 등이 있습니다. 여기서 마지막에 붙은 'P'가 Protocol의 약자입니다.

(1) TCP (Transmission Control Protocol)

• OSI 참조 모델 4계층의 전송 계층에서 사용되는 네트워크 프로토콜입니다.
• TCP는 데이터의 손실이 없이 확실하게 상대방에게 전송하기 때문에 신뢰성이 높은 프로토콜입니다. (수신 확인을 진행)
• 현재는 TCP와 IP를 조합한 TCP/IP 프로토콜이 사용되고 있습니다.

(2) IP (Internet Protocol)

• OSI 참조 모델의 3 계층인 네트워크 계층에서 사용되는 네트워크 프로토콜입니다.
• 각 장치(기기)에 주소를 할당하고 경로를 선택하여 데이터를 전송하기 위해 사용되는 프로토콜입니다.
• 상위 계층에서 패킷을 보내주면, 패킷을 수신한 뒤에 IP 헤더를 추가하여 네트워크에 전송하게 됩니다.
• IP 헤더에는 보내는 사람(수신자)의 IP 주소, 받는 사람(송신자)의 IP 주소와 같은 정보들이 모여있고, 이 정보를 가지고 경로를 선택하여 물통 릴레이 방식으로 목적지로 패킷이 전달됩니다.

(3) UDP (User Datagram Protocol)

• TCP와 마찬가지로 OSI 참조 모델 4 계층의 전송 계층에서 사용되는 네트워크 프로토콜입니다.
• TCP에서는 신뢰성을 확보하기 위해서 송신 측은 수신 측에 패킷이 정상적으로 도달했는지 확인을 진행합니다.
• UDP에서는 단순히 패킷을 보내기만 할 뿐 수신측에 패킷이 정상적으로 도달했는지 확인하지 않습니다.
• 도중에 패킷이 분신되어도 알 수 있는 방법이 없어 신뢰성은 떨어지지만 처리가 가벼워서 속도가 빠르다는 장점이 있습니다.
• 동영상과 같이 도중에 일부가 끊어지는 것보다는 실시간으로 전송되는 것이 중요한 경우에 유용하게 사용될 수 있는 프로토콜입니다.

(4) HTTP (Hyper Text Transfer Protocol)

• WWW 클라이언트(웹 브라우저)와 WWW 서버 사이의 통신에 사용되는 네트워크 프로토콜입니다.
• 웹 브라우저에서 요청이 들어오면 WWW 서버는 응답하는 방식으로 작동되는 간단한 프로토콜입니다.
• 일반적인 통신 포트는 80번 포트를 사용합니다.

💡 면접에서 나올 수 있는 질문

1. 네트워크 프로토콜이 무엇인가요?
2. 네트워크 프로토콜의 표준화가 필요한 이유에 대해서 설명해 보세요.
3. TCP와 UDP을 비교하여 설명해 보세요.