[CS] HTTP와 HTTPS(feat. ChatGPT)

질문 7: HTTP와 HTTPS

질문:

1. HTTP와 HTTPS의 차이를 설명해 주세요.
2. HTTPS가 보안을 보장하기 위해 사용하는 SSL/TLS의 주요 역할에 대해 설명해 주세요.
3. HTTPS의 인증서(Certificate)는 어떤 역할을 하며, 인증서 위조를 방지하기 위한 메커니즘은 무엇인지 간단히 설명해 주세요.

내 답변

1. HTTPS에서의 'S'는 Security를 의미하며 HTTP 프로토콜이 보안이 되었는지를 의미합니다.
2. X

3. X

---

HTTP/HTTPS

HTTP

- 데이터를 암호화하지 않은 상태로 클라이언트와 서버 간에 전송

- 데이터가 중간에서 탈취되거나 변조될 위험이 있음.

 

HTTPS

- HTTP 프로토콜에 SSL/TLS 암호화 계층을 추가하여 데이터 보안을 강화

- 데이터 암호화, 무결성, 인증을 보장

- 대칭키/비대칭키 암호화 방식 모두 사용

 

대칭키 암호화

- 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행

- 키가 노출되면 매우 위험하지만 연산 속도가 빠름

 

비대칭키 암호화

- 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함

- 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

- 공개키를 암호화 하는 경우 -> 개인키로만 복호화 할 수 있고, 개인키는 본인만 가지고 있으므로 본인만 볼 수 있다.

- 개인키를 암호화 하는 경우 -> 공개키로만 복호화 할 수 있고, 공개키는 모두에게 공개되어 있으므로 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

 

HTTPS의 동작 과정

 - HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다.

 - 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.

 - 이 세션키를 클라이언트와 서버가 어떻게 교환할까? 이 과정에서 비대칭키가 사용된다. 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용된다.

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함.

2. 서버는 공개키를 브라우저에게 넘김.

3. 브라우저는 공개키의 유효성을 검사하고 세션키를 발급함.

4. 브라우저는 세션키를 보관하며 공개키로 세션키를 암호화하여 서버로 전송함.

5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음.

6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함.

 

SSL/TLS

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 모두 암호화된 데이터 전송을 위한 프로토콜이다. TLS는 SSL의 취약성을 해결한 업그레이드된 SSL이다. 현재는 SSL 인증서는 더 이상 사용되지 않으며 TLS가 표준이지만 여전히 같은 의미로 통용되고 있다.

 

SSL 인증서 동작 원리

SSL 인증서 발급 과정

서버에서 HTTPS 프로토콜을 사용하기 위해 SSL인증서를 발급받는 과정은 아래와 같다.

 

1. 서버에서 공개키와 비밀키를 생성한다.

2. 서버는 인증서를 발급받기 위해 CA(Certificate Authority)에 1번에서 생성한 서버의 공개키와 서버의 각종 정보를 제공한다.

3. CA에서는 서버로부터 받은 정보를 담아 SSL 인증서를 발급한다.

4. 3번에서 발급한 인증서를 서명하기 위해 CA의 공개키와 비밀키를 생성하고, CA의 비밀키를 이용해 인증서를 서명한다.

5. 4번에서 서명된 SSL 인증서를 서버에 전달한다.

 

CA의 서명

 - CA는 사이트(서버) 정보와 공개키 정보를 받으면 해당 공개키를 해시(SHA-256 등)하여 인증서에 등록한다. 이 해시값을 Finger Print(지문)라고 한다. 또한 이 지문을 CA의 비밀키로 암호화하여 인증서에 서명으로 등록한다. 이 서명을 디지털 서명이라고 한다.

 - 이후 브라우저는 CA의 공개키를 이용해 서명을 복호화하여 이 값이 지문(서버의 공개키를 해시한 값)과 비교하여 인증서가 위조되지 않았음을 검증한다. 인증서의 유효성이 확인되면 브라우저는 인증서에 있는 서버의 공개키를 추출한다.

 

인증서 체인(Certificate Chain)

상위 인증 기관(CA)이 하위 인증서가 포함하고 있는 공개키를 상위 기관의 비밀키로 암호화하여 상호 보증하는 것

 

Self-Signed SSL

CA 인증 없이도 인증서를 생성할 수 있다. TLS 통신도 가능하다. CA 인증과 관련없이 발행하는 인증서가 사설 인증서이다. 이 사설 인증서는 Root CA처럼 Self-signed되어있다. 보증기관이 없으며, 보증되지 않는 인증서이다.

사설 인증서를 사용하는 경우, 클라이언트가 해당 인증서를 신뢰할 수 있는 인증 기관(CA)을 알지 못하기 때문에 보안 경고를 발생시킬 수 있다.

Root CA란?
디지털 인증서의 발급과 관리를 담당하는 신뢰할 수 있는 최상위 인증 기관.
PKI(Publikc Key Infrastructure, 공개키 기반 구조)의 핵심 구성 요소.
모든 다른 CA와 인증서의 신뢰 체계는 Root CA에서 시작된다.
Root CA 자체는 Self-Signed Certificate를 사용하여 인증서를 발급하며, 이 인증서는 다른 신뢰할 수 있는 CA에 의해 서명되지 않았음.
Root CA는 최종 사용자나 서버의 인증서를 직접 발급하기도 하지만, 일반적으로 Intermidriate CA(중간 인증 기관)를 생성하여 인증서 발급을 위임한다. 이는 보안 강화를 위해 Root CA의 키가 노출되는 것을 방지하기 위함.

 

발급받은 인증서를 통해 웹 서버와 클라이언트(웹 브라우저)가 통신하는 과정

6. 클라이언트(웹 브라우저)가 서버로 연결을 시도함.

7. 서버는 Certificate 패킷을 통해 서버의 SSL 인증서를 전달함.

8. 클라이언트는 서버의 SSL 인증서를 검증한다. CA의 공개키를 이용해 서명을 복호화하고, 복호화하여 나온 해시 값과 공개키를 해시한 값(지문)이 일치한다면, 인증서가 위조되지 않았으며 해당 CA에서 발급되었다는 것을 검증하는 것과 마찬가지이다.

9. 데이터를 암호화하기 위한 대칭키를 생성하고, 서버의 공개키로 대칭키를 암호화한다.

10. 서버로 암호화된 대칭키를 전달한다.

11. 서버는 비밀키로 복호화하여 대칭키를 얻는다.

12. 서버와 클라이언트는 대칭키를 통해 통신한다.

 

SSL Hand-Shaking

서버와 클라이언트가 주고받을 데이터의 암호화 알고리즘을 결정

서버와 클라이언트가 주고받을 데이터의 암호화를 위한 대칭키 전달

1. 클라이언트는 서버에게 "Client Hello" 패킷을 보내며 연결을 시도. 패킷에는 자신이 사용 가능한 cipher suite 목록, session id, ssl protocol version 등을 포함함.

2. 서버는 클라이언트의 "Client Hello" 메시지를 받고 클라이언트가 제안한 cipher suite 중 하나를 선택하여 "Server Hello"로 응답한다.

3. 서버는 자신의 인증서를 클라이언트에게 전송한다. 인증서에는 서버의 공개키, 인증서 발급자, 유효 기간 등이 포함되어 있다. 클라이언트는 전달받는 서버의 인증서를 검증한다.

4. 클라이언트는 서버의 공개키를 사용하여 Pre-Master Secret을 암호화하여 이를 서버에게 전송한다. 서버는 자신의 개인키로 이를 복호화하여 Pre-Master Secret을 획득한다.

Pre-Master Secret
서버의 랜덤 데이터와 클라이언트의 랜덤 데이터를 조합해 생성한 키로, 세션 단계에서 데이터를 주고 받을 때 사용됨.(대칭키 암호화 방식)

5. 이후 클라이언트는 Change Cipher Spec 메시지를 서버에게 보내어 이제부터 암호화된 통신을 시작하겠다고 알리며, 서버 또한 새로 협상된 암호화 설정을 사용할 준비가 되었다고 응답함.

6. 클라이언트와 서버는 서로에게 "Finished" 메시지를 암호화된 형태로 전송하여, 핸드셰이크 과정이 성공적으로 완료되었음을 확인한다. 이전 단계에서 협상된 Pre-Master Secret키를 사용한다.

 

 

SSL/TSL의 주요 역할

1. 암호화

- 클라이언트와 서버 간의 데이터가 중간에서 탈취되더라도 내용을 알아볼 수 없도록 암호화

- 대칭키 암호화와 공개키 암호화를 조합

2. 무결성

- 데이터가 전송 중에 변경되지 않았음을 보장

- 데이터가 변경되었는지 확인하기 위해 해시 함수와 같은 방법을 사용함.

3. 서버 인증

- 클라이언트는 서버가 신뢰할 수 있는지 확인하기 위해 서버의 SSL/TLS 인증서를 검증한다.

- 이 과정에서 서버 인증서는 CA에 의해 발급되고 서명된 상태여야 한다.

4. 보안 채널 설정

- SSL/TLS는 HandShake 과정을 통해 클라이언트와 서버 간에 안전한 통신 채널을 설정한다.

- 이 과정에서 암호화 방식과 키 교환 방식(ex. RSA)이 협상되며, 대칭키가 안전하게 공유됨.

 

수정된 답변

1. HTTP는 암호화 하지 않고 데이터를 전송하는 프로토콜입니다. 중간에 데이터가 탈취될 위험이 있습니다. HTTPS는 데이터를 암호화하여 전송하는 프로토콜입니다. 대칭키/비대칭키 알고리즘을 사용하여 데이터를 암호화합니다.

 

2. SSL/TLS의 주요 역할로는 첫번째로 암호화입니다. 클라이언트와 서버 간의 데이터가 중간에 탈취되더라도 내용을 알 수 없도록 암호화합니다. 두번째로는 무결성입니다. 해시 함수를 사용하여 데이터가 변경되었는지 확인할 수 있습니다. 세번째로는 서버 인증입니다. 클라이언트는 CA에 의해 발급되고 섬여된 서버의 SSL/TLS 인증서를 검증합니다. 마지막으로 보안 채널 설정입니다. SSL/TLS은 HandShake 과정을 통해 크라이언트와 서버 간의 안전한 통신 채널을 설정합니다.

 

3. HTTPS의 인증서는 서버를 인증하기 위해 사용합니다. CA가 서버로부터 받은 공개키와 정보로 지문을 생성하고, CA의 비밀키로 해당 지문을 암호화하여 인증서에 서명합니다. 서명된 인증서를 서버에 전달하고 이후에 클라이언트가 서버에 요청을 보내면 서버는 인증서를 클라이언트에 제공합니다. 클라이언트는 CA의 공개키로 해당 인증서를 복호화하고 복호화된 인증서와 서버의 공개키를 해시한 값을 비교하여 일치하는지 확인합니다. 일치한다면 데이터를 암호화하기 위한 대칭키를 생성하고 서버의 공개키로 대칭키를 암호화하여 서버에 보냅니다. 서버는 받은 대칭키를 개인키로 복호화하여 대칭키를 얻고 해당 대칭키를 통해 클라이언트와 서버가 통신을 합니다.

 

 

---

참고

https://mangkyu.tistory.com/98

https://kdeon.tistory.com/132