일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- kubernetes
- 클라우드
- Swift
- NGINX
- 도커 컨테이너
- linux
- 운영체제
- 도커 명령어
- C++
- centOS7
- 네트워크
- 프로세스
- k8s
- ios
- Python
- 부스트코스
- 데브옵스
- devops
- 컨테이너
- centOS
- 인프라
- docker
- 리눅스
- 쿠버네티스
- AWS
- 도커 이미지
- os
- 도커
- swift 클로저
- boj
- Today
- Total
귀염둥이의 메모
[Network] HTTP vs HTTPS, SSL/TLS, SSL/TLS handshake 본문
HTTP vs HTTPS
HTTP의 문제점은 전송되는 정보가 암호화되지 않아서 데이터를 쉽게 도난당할 수 있다. HTTPS는 HTTP 프로토콜에 암호화를 추가한 프로토콜이다. HTTPS는 SSL(Secure Socket Layer)을 사용해서 암호화된 연결을 제공한다. 클라이언트와 서버가 민감한 정보를 주고받을 때 도난당하는 것을 막아준다. HTTPS는 HTTP와 다르게 443번 포트를 사용한다.
SSL (Secure Socket Layer)
- 1973년 Netscape사에 의해 개발된 통신 규약
- 서버 인증, 클라이언트 인증, 메시지의 기밀성, 무결성 보장
- 전송계층과 응용계층 사이에 독립적인 계층을 만들어 동작한다
- 데이터 전송 시 응용 계층에서 외부로 보내는 데이터를 SSL에 보낸다
- 이를 암호화 하여 TCP로 보내고 받을 때도 TCP를 통해서 받은 암호화된 데이터는 SSL에서 복호화하여 응응 계층으로 전송
- 응용 계층은 SSL을 TCP로 인식하고, TCP는 SSL을 응용 계층으로 인식한다
주요 알고리즘
- 상호 인증 : 클라이언트와 서버 간의 상호 인증, 공개키 기반
- 기밀성 : 대칭키 암호화 알고리즘을 통한 데이터 암호화
- 데이터 무결성 : MAC(Message Authentication Code) 기법을 이용해 데이터 변조 여부 확인
TLS (Transport Layer Security)
- SSL 3.0을 IETF 표준화기구에서 표준 프로토콜로 개발
- SSL 3.0 -> TLS 1.0
- SSL == TLS
SSL을 활용한 통신
클라이언트 ↔️ 서버 통신에 앞서 서버는 CA(Certificate authority)에서 인증서를 받는다
CA(Certificate authority)
CA(인증기관)은 해당 서버가 믿을 수 있는 서버인지 검증을 거친 후 서버의 정보와 서버의 public key를 CA의 private key로 암호화하여 인증서를 제작하고 서버에게 인증서를 발급해준다. CA는 클라이언트(웹 브라우저)에게 CA의 public key를 제공한다
⭐️ 통신 방법 (SSL/TLS Handshake) ⭐️ - RSA 암호화 방식 (DH를 사용하면 뒷 부분이 조금 다름)
1. 클라이언트 ➡️ 서버 (Client hello)
- 랜덤 데이터(nonce), 브라우저에서 지원하는 암호화 기법들을 보낸다
- Reply attack을 방지하기 위해 nonce를 사용합니다
2. 서버 ➡️ 클라이언트 (Server hello)
- 서버의 랜덤 데이터(nonce)와, 서버가 선택한 암호화 방식를 전송 (클라이언트가 지원하는 암호화 방식 중에서)
- 서버의 인증서 전송(서버의 public키가 들어있다, 인증서는 CA에서 발급받았고 CA의 private key로 암호화되어있다)
3. 클라이언트는 서버로부터 받은 인증서를 통해, 해당 인증서가 신뢰할 수 있는지 확인 후 서버의 public key를 획득한다
4. 클라이언트는 pre_master_secret(대칭키) 을 서버의 public key로 암호화하여 서버로 전송한다
5. 서버는 클라이언트가 보낸 pre_master_secret(대칭키)을 서버의 private key로 복호화한다
6. 클라이언트와 서버는 모두 클라이언트의 nonce와 서버의 nonce 그리고 pre_master_secret으로 Session Key를 생성
- 클라이언트와 서버의 Session Key의 결과는 같아야 정상
7. Client / Server hello done
8. Finished (TLS Handshake 종료)
✅ 이제부터 클라이언트와 서버는 Session Key를 통해 대칭키 방식으로 통신을 진행한다 ✅
간단하게 설명된 그림
SSL(TLS) Handshake 시점
TLS handshake는 3way handshake로 TCP 연결후 수행됩니다
'CS > 네트워크' 카테고리의 다른 글
[Network] VPN (Virtual Private Network) 기본 개념 (0) | 2021.08.31 |
---|---|
[Network] 프록시 서버(Proxy Server), Forward Proxy, Reverse Proxy (0) | 2021.08.30 |
[Network] 대칭키 vs 공개키(비대칭키) 암호화 (1) | 2021.08.27 |
[Network] HTTP 프로토콜, 요청, 응답, GET, POST ... (0) | 2021.08.27 |
[Network] URI, URL, URN (0) | 2021.08.27 |