[4-3] HTTPS와 SSL/TLS

Ogu·2024년 5월 7일

현재 대부분의 웹주소는 https://~ 로 시작하는 것을 볼 수 있습니다.

HTTP는 Hyper Text Transfer Protocol의 약자로, World Wide Web의 클라이언트-서버 구조의 네트워크 통신 규약으로서 요청-응답 구조에 대한 약속을 정의하고 있습니다.

하지만 HTTP는 보안에 매우 취약하여 이를 보완한 HTTPS가 등장하게 되었습니다.

이번 시간에는 HTTPS와 HTTPS 프로토콜 종류인 SSL, TLS에 대해 알아보겠습니다.

📁 HTTP의 문제점

WWW발전과 함께 HTTP도 진화하면서, 하이퍼텍스트 문서뿐만 아니라 이미지, 비디오, HTML 폼 결과와 같은 내용을 서버로 POST하거나, 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는 데 사용하기도 합니다.

그러나 HTTP는 다음과 같은 ⛔문제가 있습니다.

보안 취약성: HTTP는 데이터를 암호화하지 않고 평문으로 전송한다. 이는 중간에 제3자가 네트워크 상에서 데이터를 엿볼 수 있으며, 개인 정보나 민감한 데이터가 노출될 수 있습니다.
ex) form 양식에 입력된 비밀번호, 신용카드 번호
- 평문(일반 텍스트) 전송 - GET 요청
```
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en
```
무결성 문제: HTTP는 데이터의 무결성을 보장하지 않는다. 데이터가 전송 중에 변경되거나 조작될 수 있으며, 이로 인해 정보의 정확성이 보장되지 않는 문제가 있다.
신원 보증의 부재: HTTP는 서버의 신원을 확인하는 기능이 없다. 따라서 중간에 제3자가 서버를 위장하여 클라이언트와 통신할 수 있으며, 이는 사이버 공격의 가능성을 높이는 요인이 된다.

📁 HTTPS

HTTPS는 HyperText Transfer Protocol Secure 의 약자로, HTTP통신에 Secure를 결합한 형태입니다.

위에서 설명한 것과 같이 HTTP에는 보안 및 무결성에 취약하기 때문에 HTTP에 통!
신 자체를 암호화하는 SSL(Secure Socket Layer) 또는 TLS (Transport Layer Security)라는 프로토콜을 조합한 HTTPS를 사용하기 시작했습니다.

이는 기존 OSI 7계층의 구조에서 Application계층 → SSL/TSL 계층 → Transport(전송)계층 과 같은 흐름으로, 안전한 계층을 응용계층과 전송계층 사이에 추가하여 데이터를 보안하고 압축하는 서비스를 제공합니다.

https://blog.eleven-labs.com/en/understanding-ssltls-part-1/

콘텐츠 내용, 즉 HTTP 메시지에 포함되는 콘텐츠를 암호화하므로, 응답을 받는 측에서는 디코딩하여 해석해야 합니다.

암호 문자열 위에서 본 평문(텍스트) 형식 대신 아래와 같이 무작위로 보이는 암호화된 문자열을 보게됩니다.

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

🗂️ 프로토콜 구조

https://velog.io/@duck-ach/Security-SSLTLS-개념-및-통신-프로세스

HandShake : 양쪽 간에 연결을 설정할 때 보안 협상을 위한 프로토콜
Change Cipher Spec : 보안 파라미터를 변경하거나 적용할 때 사용. 예를들어 대칭키 알고리즘을 변경할 때 이 프로토콜 사용
Alert : 오류, 비정상
Application Data : 실제 데이터
Record : 협상된 보안 파라미터를 이용하여 암호화, 복호화, 무결성 등을 수행
- 순서 : 단편화 ➔ 압축 ➔ MAC첨부 ➔ 암호화 ➔ SSL 레코드 헤더 붙이기

🔔HTTPS의 기본 포트

HTTP : 80

HTTPS : 443

실습

웹사이트 URL 뒤에 :80, :443 과 같이 포트 번호를 포함하여 접속해봅시다.

https://www.naver.com:443 접속 O

http://www.naver.com:80 : 접속 O

하지만 http로 접속하면 크롬 브라우저에 의해 https로 다시 리다이렉트되어 url로 이동되는 것을 볼 수 있습니다.

참고) chrome브라우저에서 이를 해제하는 설정이 있습니다.

🗂️ SSL

SSL이란 보안 소켓 계층(Secure Sockets Layer)으로서 C언어로 작성되었으며, 사용자와 서버 간의 데이터를 암호화하는 보안 프로토콜입니다.

SSL은 대칭키 방식이나 공개키 방식 같은 데이터 암호화 기법 중 하나를 선택하여 핸드셰이크를 통해 동작합니다. 일반적으로는 RSA 키 교환 알고리즘(공개키)이 사용됩니다.

핸드셰이크

핸드셰이크는 브라우저가 서버의 SSL 또는 TLS 인증서를 인증하는 프로세스입니다. 이 프로세스는 양 당사자를 인증한 다음 암호화 키를 교환합니다.

https://www.crocus.co.kr/1387

🔍참고) 자세한 과정 설명
1. 악수 (handshake)
Step 1 | Client Hello
1. 클라이언트가 서버에 접속(Client Hello)한다. 이 단계에서 주고 받는 정보는 아래와 같다.
  - 클라이언트 측에서 생성한 랜덤 데이터 : 아래 3번 과정 참조
  - 클라이언트가 지원하는 암호화 방식들 : 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 한다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송한다.
  - 세션 아이디 : 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송한다.
  
  Step 2 | Server Hello
  
  서버는 Client Hello에 대해 Server Hello로 다음 3가지를 응답한다.
- 서버 측에서 생성한 랜덤 데이터
- 서버가 선택한 클라이언트의 암호화 방식
- 인증서 with 공개키
  
  Step 3 | 인증서 확인, Pre Master Secret 키 생성
- 클라이언트는 내장되어있는 CA 리스트에서 각 CA의 공개키를 이용하여 서버가 보낸 인증서를 복호화한다.
  - 만약 CA리스트에 없는 인증서라면 사용자에게 경고의 메시지를 띄운다.
- 만약 복호화에 성공하면
  - 해당 인증서는 CA의 개인키로 암호화 한 문서임이 보증되었기 때문에 서버를 신뢰할 수 있게 된다. ( 개인키로 암호화 -> 공개키로 복호화 )
  - 클라이언트가 전송한 랜덤한 데이터 + 서버가 전송한 랜덤한 데이터 를 조합하여 Pre Master Secret 키를 생성한다. → 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해서 사용
  
  Step 4 | Pre Master Secret 키 서버로 전송
- Step 2에서 받은 공개키를 이용해 Pre Master Secret 키를 암호화하여 서버로 전송한다.
```
이 때 Pre Master Secret 키는 절대 노출되어선 안된다. 

- 암호화 기법이 대칭키이기 때문
- 공개키는 인증서에 포함되어 있음
```
  Step 5 | 서버에서 Pre Master Secret 키 복호화
- 서버는 Pre Master Secret 값을 자신의 비밀키로 복호화
  
  → 클라이언트와 서버는 Pre Master Secret 키를 공유하게 됨
1. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다. 이로서 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되었다. 그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만든다. master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후에 주고 받는다. 이렇게해서 세션키를 클라이언트와 서버가 모두 공유하게 되었다는 점을 기억하자.
2. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.
  
  Step 6 | master secret → session key 생성
- 서버와 클라이언트는 일련의 과정을 거쳐 Pre Matser Secret → Master Secret 값으로 만든다.
```
그리고 Master Secret를 이용하여 **Session Key**를 만든다.
```
  2. 세션
  
  세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다.
- 클라이언트와 서버간의 세션이 형성하고, Session Key(대칭키 방식)를 이용하여 암호화하여 데이터를 주고 받는다.
  
  3. 세션종료
  
  데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다.
  
  이 때 통신에서 사용한 대칭키인 세션키를 폐기한다.

클라이언트가 서버에 접속하면 서버 인증서(서버의 공개키를 인증기관이 전자서명으로 인증한 것)를 전송받는다. (클라이언트 인증을 필요로 할 경우 클라이언트의 인증서를 전송)
클라이언트는 받은 서버 인증서를 분석하여 신뢰할 수 있는 인증서인지 검토 → 서버의 공개키 추출
클라이언트가 세션키로 사용할 임의의 메세지를 서버의 공개키로 암호화하여 서버에 전송합니다.
서버에서는 자신의 개인키로 세션키를 복호화하여 그 키를 사용하여 대칭키 암호방식으로 메시지를 암호화하여 클라이언트와 통신하게 됩니다.(https://)

🔔 비대칭키 암호 방식은 대칭키 암호방식보다 상당히 느리다.
따라서 SSL은 암호화된 데이터를 전송하기 위해 대칭키/비대칭키 암호화 방식을 혼합하게 된다.
채널을 수립할 때는 공개키, 비공개키를 통해 안전한 채널을 설립하고 그 이후에는 대칭키를 통해 데이터를 암호화하여 주고 받는다.

SSL 인증서

SSL 인증서는 사용자가 접속하고자 하는 서버가 신뢰할 수 있는 서버라는 것을 공인된 업체(CA, Certificate authority)가 보장하는 것입니다.

SSL인증서는 공인된 업체, CA를 통해서 구입이 가능합니다.

🗂️ TLS

TLS는 Transport Layer Security의 약자로, 2.0의 취약점 보완을 위해 크게 구조 변경된 SSL 3.0v를 배포한 이후 이전 버전과 구분하기 위해 변경된 정식 명칭입니다.

❓ SSL과 TLS 인증서 중 어떠한 것을 사용하나요?

현재 모든 SSL 인증서가 더 이상 사용되지 않습니다. TLS 인증서가 업계 표준이지만 업계에서는 기존의 SSL 이라는 단어가 더 익숙하기 때문에, TLS 인증서를 지칭하는 데 SSL이라는 용어를 계속 사용합니다.

인증서 이름이 SSL 인증서라도 이미 SSL 프로토콜과 TLS 프로토콜을 모두 지원합니다.

🗂️ TLS/SSL의 HTTP 요청과 응답 암호화

TLS는 공개 키 암호화(비대칭키)라는 기술을 사용합니다.

공개키 암호화는 비대칭 키 암호화 라고도 하며, 공개 키와 개인 키를 사용합니다.

공개 키는 서버의 SSL 인증서를 통해 클라이언트 장치와 공유됩니다.

클라이언트가 서버와의 연결을 열면 두 장치는 공개 키와 개인 키를 사용하여 세션 키라는 새 키에 동의하여 두 장치 간의 추가 통신을 암호화합니다.

모든 HTTP 요청과 응답이 이 세션 키로 암호화되므로 통신을 가로채는 사람은 일반 텍스트가 아닌 임의의 문자 문자열만 볼 수 있습니다.

https://liveyourit.tistory.com/183

🗂️ SSL과 TLS의 차이점

SSL과 TLS의 용도는 매우 유사하지만 이들 통신 프로토콜은 작동 방식이 다릅니다. 이러한 변경 사항은 SSL이 TLS로 대체되기 전에 다양한 버전을 거치면서 시간이 지남에 따라 발전했습니다.

SSL/TLS 핸드셰이크

SSL 핸드셰이크는 명시적 연결인 반면 TLS 핸드셰이크는 암시적 연결입니다. SSL 핸드셰이크 프로세스는 TLS 프로세스보다 단계가 더 많았습니다. TLS는 추가 단계를 제거하고 총 암호 그룹 수를 줄여서 프로세스 속도를 높였습니다.

알림 메시지

SSL 및 TLS 프로토콜은 알림 메시지를 통해 오류와 경고를 전달합니다.

SSL에는 경고와 치명적이라는 두 가지 알림 메시지 유형만 있습니다. 또한 SSL 알림 메시지는 암호화되지 않습니다.

경고(Warning) 알림 : 오류가 발생했지만 연결을 계속할 수 있음
치명적(fatal) 알림 : 연결을 즉시 종료해야 함

TLS에는 **닫기 알림이라는 추가 알림 메시지 유형이 있습니다. 닫기 알림은 세션 종료를 알립니다. 또한 TLS 알림은 추가 보안을 위해 암호화됩니다.

메시지 인증

SSL과 TLS 모두 메시지의 진본성과 무결성을 확인하기 위한 암호화 기술인 메시지 인증 코드(MAC)를 사용합니다. 레코드 프로토콜은 보안 키를 사용하여 MAC을 고정 길이 코드로 생성하고 원본 메시지에 첨부합니다.

SSL 프로토콜은 MAC 생성에 MD5 알고리즘(현재는 구식)을 사용합니다. TLS는 더 복잡한 암호화와 보안에 해시 기반 메시지 인증 코드(HMAC)를 사용합니다.

암호 그룹

암호 그룹은 브라우저와 서버 간의 정보를 암호화하기 위한 키를 생성하는 알고리즘 모음입니다. 일반적으로 암호 그룹에는 키 교환 알고리즘, 검증 알고리즘, 대량 암호화 알고리즘 및 MAC 알고리즘이 포함됩니다. 보안 문제로 인해 TLS의 여러 알고리즘이 SSL에서 업그레이드되었습니다.