[Network] HTTP와 HTTPS

HTTP (Hypertext Transfer Protocol)

웹에서 통신할 때 사용하는 가장 기본적인 프로토콜

클라이언트와 서버가 주고 받는 메세지의 형식에 대한 약속이다.

 

1. 평문 통신이므로 도청이 가능하다.

HTTP는 서버에서 브라우저로 전송되는 정보가 암호화되지 않는다.

암호화 하지 않은 평문을 보내기 때문에 제 3자가 훔쳐볼 수 있다.

 

2. 완전성을 증명할 수 없으므로 변조가 가능하다.

HTTP는 메세지가 중간에 변경되어도 알 수 없다.

클라이언트에서 메세지를 보내도 공격자가 메세지를 변경해도 서버는 받은 메세지가 변경이 된지 알 수 없고

클라이언트도 자신이 보낸 원본의 메세지가 잘 도착되었는지 알 수 없다. 

 

3. 통신 상대를 확인하지 않으므로 위장이 가능하다.

HTTP는 올바른 상대와 통신하고 있는지 알 수 없다.

서버에서는 요청이 날라왔을 때 권한이 없는 클라이언트로 부터 온 것인지 알 수 없고

클라이언트도 본인이 진짜 웹 서버에게 보내고 있는 것인지 위장한 웹 서버에게 보내고 있는 것인지 알 수 없다.

---

HTTPS (Hypertext Transfer Protocol Secure)

SSL(보안 소켓 계층) 사용

SSL은 클라이언트와 서버 사이에 안전하게 암호화된 연결을 만들 수 있게 도와줌.

클라이언트와 서버가 민감한 정보를 주고받을 때 해당 정보가 도난당하는 것을 막아줌.

HTTPS는 HTTP에서 정보가 암호화되지 않는다는 문제를 SSL을 활용해서 해결하였다.

HTTP를 사용해서 운반하는 내용 즉, HTTP 메세지 바디를 암호화한다.

 

SSL/TLS (Secure Sockets Layer / Transport Layer Security)

 

Netscape Communications Corporation에서 웹 서버와 웹 브라우저간의 보안을 위헤 만든 프로토콜이다.

SSL / TLS 이라는 다른 프로토콜을 조합하여 안전한 통신로를 확립한다. SSL은 공개키/개인키, 대칭키 방식을 혼합하여 사용한다.서버와 브라우저간 전송되는 데이터를 외부의 공격자로부터 보안하기 위해 필요하다. 암호화의 대상은 내용이 유출되었을 때 악용되어 사용될 수 있는 비밀번호나 개인정보 등이 해당된다.

 

대칭키

• 대칭키 방식은 동일한 키로 암호화/복호화를 수행하는 방법이다.
• 누구든지 암호화에 이용된 키를 가지고 있으면 해당 데이터를 쉽게 복호화할 수 있다.

공개키

• 공개키 방식은 서로 다른 키로 암호화/복호화를 수행하는 방법이다.
• 그래서 공개키는 비대칭키 방식으로도 불린다.
• 데이터 암호화 시에는 공개키를 사용하고 복호화 시에는 개인키를 사용한다. 
• 서버측에서 개인키를 보관하고, 암호화된 데이터를 해독할 수 있는 곳은 서버뿐이다.
• 공개키로 암호화된 데이터는 오직 개인키로만 복구할 수 있기 때문에 누구든지 공개키를 가져도 상관이 없다.
• 즉, 중간에 해커가 가로챈다 하여도 문제가 되지 않는다.

대칭키 방식은 암호화/복호화가 쉽다는 장점을 가지고 있다. 반면에, 결국 한번은 한쪽에서 다른 쪽으로 키를 전송해야 하는데 중간에 누가 이것을 훔쳐본다면 소용없기 때문에 키를 공유할 때 문제가 생길 수 있는 단점을 가지고 있다. 공개키 방식은 공개키를 얼마든지 공유해도 되기 때문에 키 배송에는 문제가 없지만 대칭키 방식보다 암호화/복호화 연산시간이 더 소요되어 비용이 크다는 단점이 있다. 그래서 SSL은 각 방식이 가진 단점 때문에 하나의 방식만 채택해 사용하지 않고 두 방식을 적절히 섞어 사용하게 된다.

 

SSL 통신 과정

SSL은 공개키 방식으로 대칭키를 전달한다. 이 대칭키를 활용해서 암호화/복호화를 하고 서버와 브라우저간의 통신을 진행한다.

 

A에서 B로 접속 요청을 보낸다.

 

이때, B는 A에게 자신의 공개키를 전송한다.

 

 

A는 자신의 대칭키를 B에서 전달받은 B의 공개키로 암호화한다.

 

이렇게 암호화 한 대칭키를 B에게 전달한다.

 

B는 A의 대칭키를 자신의 개인키로 복호화한다.

 

이 복호화한 결과로 B는 A의 대칭키를 얻어낼 수 있다.

이렇게 얻어낸 대칭키를 활용해서 A와 B는 안전하게 통신한다.

 

즉, 데이터 암호화/복호화를 위한 한쪽의 대칭키를 다른쪽의 공개키로 암호화하여 전송하면 반대편에서 자신의 개인키로 복호화하여 그 반대편의 대칭키를 알아내고 이 대칭키를 바탕으로 서로 통신하게 된다.

 

공개키 암호화의 문제점

• 공개키가 진짜인지 아닌지 증명할 수 없다.
• 신뢰할 수 있는 기관에서 서버의 공개키만 검증해준다면 클라이언트는 안전하게 웹사이트를 이용할 수 있을 것이다.
• 서버가 우리에게 공개한 공개 키가 정품인지를 확인할 수 있어야 한다.
• 이걸 인증해주는 공인된 민간기업들이 있다. Certificate Authority, 줄여서 CA 라고 부른다.

 

SSL 인증서

• 사이트는 사이트 인증서가 필요하다. 
• 사이트 인증서는 인증기관(CA)에서 사이트에게 발급해주는 문서이다.
• 이를 위해 사이트에서 인증기관에게 사이트 정보와, 사이트 공개키를 전달한다.
• 인증기관에서는 사이트 인증서를 발급하기전에 전달받은 데이터를 검증한다.
• 인증기관에서 성공적으로 검증을 완료하면 인증기관은 사이트 인증서를 생성하기 위해 이 데이터를 자신의 개인키로 서명한다.
• 서명을 하고나면, 사이트 인증서가 생성이되고, 생성한 인증서를 사이트에게 전달한다.
• 인증기관은 사용자에게 자신의 공개키를 전달한다.
• 이때, 사용자가 인증기관으로부터 전달받은 인증기관의 공개키는 사용자 브라우저에 자동으로 내장된다.
• (대부분의 브라우저에서는 공신력있는 CA들의 정보와 CA가 만든 공개키가 이미 설치되어있다.)

정리

1. 서버는 SSL 인증서를 제공한다. 이 인증서에는 서버측의 공개키와 서비스의 정보(도메인)를 담고있다.
2. 브라우저는 이 인증서를 발급한 CA가 자신의 CA리스트에 있는지 확인한다.
3. 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화한다. 

복호화가 된다면 이 인증서는 CA의 비공개키에 의해 암호화 되었다는 것을 알 수 있다

---

SSL 핸드쉐이크 (SSL Handshake)

클라이언트와 서버가 안전한 연결을 설정하기 위해 수행하는 초기 과정이다.

이 과정에서 암호화 방식, 인증, 키 교환 등이 이루어진다. HTTPS 통신의 핵심 단계로, 안전한 데이터 전송을 가능하게 합니다.

 

SSL 핸드쉐이크의 주요 목적

1. 서버와 클라이언트의 신원 확인
   • 서버 인증 (필수)
   • 클라이언트 인증 (선택)
2. 암호화 방법 협상
   • 사용할 암호화 알고리즘과 키 교환 방식 결정.
3. 세션 키 교환
   • 데이터를 암호화/복호화할 대칭 키를 공유.

 

SSL 핸드쉐이크 과정

1. client Hello: client에서 SSL버전 정보와 지원하는 암호화 방식, 무작위 바이트 문자열(이후에 사용하게 되는 중요한 데이터입니다)이 포함 되어 전달된다. 이미 SSL handshake를 했었다면 세션을 재사용 할 수 있다.
2. server Hello: 지원하는 암호화 방식 중 서버에서 어떤것을 사용할 지, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송한다. 클라이언트에서 인증서를 요구하게 되면 SSL 인증서를 전송하게 된다.
3. 인증서를 받게 되면 해당 CA의 공개키를 이용해서 인증서를 복호화하고 신뢰할 수 있는 사이트 인지 판단하게 된다. 이 과정을 통해 클라이언트는 공개키를 얻게 된다.
4. 이후 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버쪽에서 전송된 무작위 바이트 문자열을 조합하여 pre-master secret키를 생성한다. 이 키는 이후 데이터를 주고 받을 때 대칭키 방식을 사용할 때 사용하게 된다. 이 pre-master secret키를 서버로 전송할 때 인증서에서 받았던 키를 이용하여 공개키 방식 암호화를 하게 된다. 그리고 서버쪽으로 전송하게 된다.
5. 서버쪽에서는 수신한 pre master secret키를 비밀키를 이용하여 복호화 하여 얻게 된다.
6. server client 둘 다 일련의 과정을 거쳐 pre-master secret키를 master key로 만들게 되고 이 master key를 이용하여 session key를 만들게 된다. 이후 데이터를 주고 받을 떄 session key를 대칭키 방식으로 이용하여 통신하게 된다.
7. 통신이 끝나면 세션키를 폐기한다.

 

 

요약한 과정

 

1. 클라이언트 헬로 (Client Hello)
클라이언트가 서버에 다음 정보를 전송

• 지원하는 암호화 방식 목록 (예: RSA, AES)
• 사용할 TLS 버전
• 난수(랜덤 데이터) ClientRandomClient RandomClientRandom
• 세션 ID (이전 세션 재활용 시)

2. 서버 헬로 (Server Hello)
서버가 클라이언트에 응답하며 전송:

• 선택한 암호화 방식
• 사용할 TLS 버전
• 난수(랜덤 데이터) ServerRandomServer RandomServerRandom
• 세션 ID

3. 서버 인증 및 키 교환:

• 서버는 SSL/TLS 인증서를 클라이언트에 전송:
  • 인증서에는 서버의 공개 키와 신뢰 기관(CA)의 서명이 포함.
  • 클라이언트는 CA를 신뢰하는지 확인.
• 서버는 공개 키를 사용해 클라이언트가 보낼 데이터를 복호화할 준비를 함.

4. 클라이언트 키 교환 (Client Key Exchange)

• 클라이언트는 서버의 공개 키를 사용해 프리마스터 시크릿 (Pre-Master Secret)을 암호화하여 서버에 전송.
• 서버는 자신의 비공개 키로 이를 복호화해 대칭 키를 생성.

5. 세션 키 생성

• 클라이언트와 서버는 Pre-Master Secret, Client Random, Server Random을 사용해 세션 키를 생성.
• 이 세션 키는 이후의 통신을 암호화하는 데 사용.

6. 완료 메시지 교환

• 클라이언트와 서버는 각각 "핸드쉐이크 완료" 메시지를 교환.
• 이후 암호화된 통신 시작.

 

 

과정 예시)

사용자가 사이트에 접속을 요청한다. 

사이트는 자신이 신뢰할 수 있는 사이트임을 증명하기 위해 사용자에게 자신의 인증서를 전달한다.

사용자는 브라우저에 내장되어 있는 인증기관 공개키로 사이트 인증서를 복호화하여 검증한다.

사이트 인증서를 해독하면 사이트 정보와 사이트 공개키를 얻을 수 있다.

이렇게 얻은 사이트의 공개키로 사용자는 자신의 대칭키를 암호화 하고 사이트에게 전달한다. 

이어서 사이트는 자신의 개인키로 사용자로부터 전달받은 암호문을 해독하여 사용자의 대칭키를 얻는다.

이렇게 얻은 대칭키를 이용하여 사용자와 사이트는 암호문을 주고받을 수 있게 된다.

즉, SSL 통신을 하게 된다. SSL은 사이트 외의 인증기관과 사용자도 협력하기 때문에 안전한 접속 방법이 된다.

---