HTTPS와 암호화 메커니즘

학교 팀플 과제 중 처음으로 인프라 파트를 전담하게 됐는데, 원래 HTTP로 편하게 개발하다가 프론트 팀원의 요청으로 HTTPS로 변경해야 하는 상황이 발생했다.

 

그런김에 예전에 보안 수업 때 들었던 암호화 내용과 겹쳐서 정리해보았다.

 

 

1. 왜 HTTP 대신 HTTPS를 써야하나 ?

웹 통신의 기본인 HTTP는 데이터를 전송할 때 암호화되지 않은 날것의 텍스트를 네트워크망에 던진다.이는 중간에 해커가 와이파이 신호를 탈취하여 슥 읽어버리면(스니핑, Sniffing) 보안이 그대로 뚫리게 된다.

그래서 HTTPS를 도입해야 하는 핵심 이유는 크게 두 가지다.

1. 데이 터 암호화: 해커가 중간에서 데이터를 훔쳐 가도, 암호화되어 있어 읽지 못하게한다
2. 신분 위조 방지 (인증): 사용자가 내 도메인(서버)에 접속했을 때, 공인된 진짜 서버가 확실하다는 것을 보증한다

2. CA(인증 기관)

인터넷 세상에서 아무나 "내가 네이버다", "내가 무슨 서버다!!!"라며 가짜 인증서를 만들어 배포하면 피싱 사기가 판칠 것이다.이를 막기 위해 디지털 세상에는 CA (인증 기관)라는 공인된 인증기관같은 존재가 있다. 대표적인 기관이 바로 오픈소스 CA인 Let's Encrypt가 있다

우리가 EC2 환경에서 수동으로 실행했던 Certbot은
이 구청(CA)에 가서 저 이 도메인 진짜 주인 맞는데 신분증 주세요 하고 접수하는 대리인 역할을 한 것이다.

그 결과 CA로 부터 정식 발급받아 EC2 서버의 /etc/letsencrypt 에 저장된 핵심 파일 2개가 바로 이거다

• fullchain.pem (공개키, Public Key)
  • 기관이 인증한 우리 서버의 신분증이자 누구나 볼 수 있는 키.
  • Nginx 웹 서버가 접속하는 손님들에게 가장 먼저 뿌리는 파일.
• privkey.pem (개인키, Private Key)
  • 내 서버만 가진 키
    
    

3. HTTPS 연동 및 암호화/복호화 메커니즘 (SSL Handshake)

사용자의 브라우저와 내 백엔드 서버가 만나 안전하게 통신을
시작하기까지의 과정을 SSL/TLS 핸드셰이크라고 한다.

💡참고로 공개키는 비공개키로 열 수있고 비공개키는 공개키로 열 수있다

- 디지털 서명 : 보내는 쪽의 private key로 암호화하는거 (신원 증명용)
- 암호화 : 보내는 쪽의 public key로 암호화 하는거 (기밀성 보장용)
- 대칭키는 암호화key == 복호화 key (세션키)
- 비대칭키는 암호화 key /= 복호화 key인데
대칭키는 빠르고 대용량처리가 가능한 장점이 있지만 이 공개키를 어떻게 서로 공유할지가 문제점임 ! 그래서 보통 파일 암호화에 많이 쓰인다
비대칭키는 공유에 대한 무제가 없긴한데 대칭키에 비해서 느리고 대용량에 적합하지 X

=> 그래서 보통 처음에는 안전하게 대칭키를 공유하려고 비대칭키를 쓰고 키 공유가 끝나고 데이터를 주고 받을 때는 대칭키를 쓰는 혼합 아키텍처를 쓴다.

 

1단계: Client Hello (손님이 문을 두드림)

사용자가 브라우저 주소창에 https://우리서버를 입력하면, 브라우저가 서버에 내가 지원하는 암호화 방식 목록은 이거야~ (TLS프로토콜 버전정보나 , 해독할 수있는 암호화 알고리즘 등) 하고 데이터를 보낸다.

 

2단계: Server 인사 & Certificate (서버의 신분증 제시)

서버가 인사를 받고, 오케이, 이 암호화 방식을 쓰자. 그리고 나 사기꾼 아니니까 내 신분증 보여줄게! 하며 Certbot으로 발급받았던 fullchain.pem 를 브라우저에게 던져준다.

 

ppt로 그림을 그려봤는데 이런 느낌으로 이해하면 편하다

 

3단계: Certificate Verification (인증서 검증 )

크롬, 사파리 같은 브라우저의 뇌 속에는 전 세계 공인 구청(CA)들의 공개키 가 이미 있음!

4단계: Pre-Master Secret 전송 (일회용 비밀번호 통 전달)

신뢰가 쌓였으니 진짜 데이터를 주고받을 비밀번호(대칭키, 세션 키)를 공유해야 한다.
브라우저가 무작위로 이 비밀번호를 하나 생성한 뒤, 우리 서버의 공개키로 비밀번호 암호화해서 우리 서버에 던진다

 

 

 

5단계: 비밀번호 획득 (Decryption)

우리 서버가 개인키로 브라우저가 보낸 메세지 연다.
이로써 서버와 브라우저가 똑같은 비밀번호를 완벽하게 공유하게 된다.

 

6단계 & 7단계: 대칭키를 통한 고속 API 통신 (Symmetric Encryption)

Handshake가 끝났다. 비대칭키 구조는 컴퓨터 연산 속도를 너무 많이 잡아먹기 때문에, 실제 대용량 데이터가 오고 가는 본 통신에서는 방금 공유한 대칭키로 통신한다.

즉 프론트엔드가 보낸 정보, 스프링이 진짜 API Response 결과물 등 모든 Message는 이 대칭키로 빠르게 서로 암호화/복호화되며 안전하게 오고 간다.

 

끝 !