HTTPS

HTTP VS HTTPS

• HTTP에서 보안이 강화된 프로토콜
• 누구나 볼 수 있었던 메시지를 통신하는 당자들끼리만 볼 수 있도록 암호화

SSL

• Secure Sockets Layer
• 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있도록 돕는 보안 계층

암호화 기법

대칭키 기법

하나의 키로 암호화와 복호화를 둘 다 할 수 있는 기법

• 서버와 클라이언트가 같은 키를 갖고 있다가 데이터를 보낼 때 이 키를 사용하여 암호화하여 전송, 데이터가 왔을 때 이 키로 복호화
• 단점 : 키를 안전하게 서로 교환하기 어려움(탈취 우려)
  → 해결법 : 공개키
  

공개키 기법(비대칭키 기법)

서로 다른 두 개의 키(공개키, 개인키)로 암호화, 복호화

• 공개키 : 누구나 가질 수 있는 키
• 개인키 : 소유자 한 명만 가질 수 있는 키
  
• 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있고, 개인키로 암호화한 데이터는 공개키로만 복호화할 수 있다.
• 만약 클라이언트가 개인키를 갖고, 서버에게 공개키를 전달한다면, 중간에 공개키를 가로 챘다고 해도 개인키를 모르기때문에 데이터를 온전히 복호화할 수 없음
• 단점 : 암호화 과정이 복잡하므로 속도가 느리다(대칭키 기법과 알고리즘이 다름)
  → SSL에서는 공개키 기법과 대칭키 기법을 함께 사용하여 서로의 단점을 보완
  

SSL 동작 과정

핸드 셰이크, 세션, 세션 종료

SSL 핸드 셰이크는, TCP 연결이 성립된 상태에서 진행

핸드 셰이크

TCP와 유사하게 SSL에서도 클라이언트와 서버가 통신할 때 준비가 되었는 지 확인하는 과정인 핸드 셰이크를 거침

1. Client Hello
   랜덤한 데이터와 지원가능한 암호화 방식 목록을 서버에게 전달

2. Server Hello
   랜덤 데이터, 목록 중 선택한 암호화 방식, SSL인증서를 클라이언트에게 전달

• SSL인증서 : 공식으로 인증된 기관인 CA에서 발급한 문서로, 서버가 신뢰할 수 있는 지 보장하는 역할
• CA의 개인키로 암호화 되어 있음
• 서버의 공개키가 들어가있음
• 서버의 정보가 들어가있음
• 서버가 CA로부터 미리 발급 받아놓은 상태

3. 서버 인증서 확인 및 임시 대칭키 생성

• CA의 공개키를 통해 인증서를 복호화 → 복호화 성공한다면 이 인증서는 CA에서 서명한 것임을 증명
• 인증서에서 얻은 서버의 정보와 해당 서버가 일치하는 지 체크

4. 클라이언트는 서버와 주고 받은 랜덤 데이터를 조합하여 premaster secret을 만들고, 서버의 공개키로 암호화해서 전송
5. 암호화된 premaster secret을 받은 서버는 자신이 갖고 있는 개인키로 복호화함
6. 클라이언트와 서버는 premaster secret와 랜덤데이터를 조합하여 master secret으로 만들고, master secret을 사용하여 세션키 생성

세션

세션키를 이용하여 대칭키 기법으로 데이터를 암호화/복호화를 통해 통신

세션 종료

데이터 전송이 끝나면 세션키를 삭제하여 통신을 끝냄

💡 TLS
SSL에서 발견된 취약점을 해결한 계층으로, 대다수의 보안 프로토콜이 TLS로 교체되어 더이상 SSL을 사용하지 않음.
(SSL3.0이후부터 이름을 TLS로 변경했지만, SSL이름이 익숙해서 지금까지도 계속 SSL이라고 부름)