How HTTPS works? : HTTPS와 SSL 인증서

🚀 HTTPS

HTTP는 hypertext transfer protocol의 약자이다.

hypertext는 HTML을 말하므로 "HTML 전송 통신규약"이라고도 할 수 있다.

HTTPS는 여기에 S(Secure)가 추가된 것이다. 

 

 

🚀 왜 HTTPS가 필요할까?

 

1. 개인 정보 보호 => 메세지 암호화. 클라이언트 측에서 보낸 해쉬화 되기 이전의 패스워드를 탈취 당하면 당연히 해킹. 이를 '스니핑 공격'이라고 함.

 

2. 무결성 =>  메시지가 암호화하여 중간자가 메세지를 조작하는 것을 방지. 중간자가 마치 정상적인 유저가 보낸 것처럼 위장하여 개인정보 요청을 받아 해커가 취득하거나, 강제 탈퇴 시키는 등의 조작을 가할 수 있음. 이를 '스푸핑 공격'이라고 함.

 

3. 식별 => HTTPS는 SSL 인증서를 통해 수신자에게 정확하게 연결해 줌.

 

 

🚀 대칭키 암호화와 비대칭키 암호화

 

이미 정리해두었다.

 

darrengwon.tistory.com/1031?category=858372

공개키 암호, 전자 서명, 메세지 해싱에 대한 개념적 이해

https는 당연히 암호학적으로 더 보안성이 뛰어난 비대칭키 암호를 기반으로 소통이 이루어진다.

 

 

 

🚀 CA(Certificate authority) 기업

 

대표적인 CA 기업 Symantec

SSL 인증서를 발생하는 곳이 CA다. 

CA는 비공개키를 가지고 있다. 이 비공개키가 유출되면 신용카드나 비밀번호와 같은 정보들을 탈취할 수 있게 된다.

따라서 CA는 아무 기업이나 할 수 있는 것이 아니라 엄격한 기준에 따라 공인된 기업만 가능하다. 
대표적 기업으로 Symantec(VeriSign, Thawte, Geotrust 인수), Comodo 등이 있다.

각 브라우저(chorm, ie...)는 특정 CA를 지정하여 CA가 발행한 인증서를 브라우저가 인식할 수 있게끔 한다. 브라우저의 소스 코드에는 인정한 CA의 리스트가 들어 있다.

웹사이트를 운영하는 곳에서는 CA 기업에 인증서에 대한 비용을 치루고 인증서를 이용할 수 있게 된다. 
(물론 무료도 존재한다) 

개발 목적으로 https가 필요하다면 자신이 직접 CA의 역할을 할 수도 있다. 다만 공인된 인증서가 아니기 때문에 브라우저가 경고를 보낸다

 

 

🚀 SSL 디지털 인증서 

클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서. 
클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 인증서를 전달한다. 
클라이언트는 이 인증서를 신뢰할 수 있는 지 검증한다.

 

인증서가 하는 역할은 compact하게 설명하자면 다음과 같다.

 

• 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

인증서에는 서비스의 정보(CA, 서비스 도메인 등)와 서버 측 공개키가 들어 있다.

 

 

 

🚀 https 커넥션

 

네트워크 통신 별로 SSL의 암호화 방식을 살펴보자. (코더가 이 방식을 관찰할 수는 없다. 자동으로 이뤄지기 때문에)

1. 핸드쉐이크 => 2. 세션 => 3. 세션 종료

 

핸드쉐이크?

서버와 브라우져(클라이언트)가 안전하게 의사 소통하는 방법을 만드는 과정.

1. 클라이언트야 안녕.(client hello)

브라우저가 SSL / TLS 버전 및 암호화 알고리즘 목록(cipher suite)을 서버에게 보낸다.

2. 서버야 안녕.(client hello)

브라우저가 보낸 것 중 가장 좋은 SSL/TLS 버전과 암호화 알고리즘을 서버의 선호도에 따라 선택하여 서버의 공개키가 포함된 SSL 인증서를 보낸다.

3. 클라이언트 키 교환.

클라이언트(브라우저)는 가진이 가진 CA 리스트를 체크하여 인증서를 살펴 서버가 보낸 인증서가 합법적인지 확인한다. 동시에 인증서에 있는 서버의 공개키를 취득한다.

또, 브라우저는 pre-master key를 만들고 서버가 보낸 SSL 인증서에 동봉된 공개 키로 암호화 하여 서버에게 전달한다.

pre-master key는 클라이언트와 서버 양쪽 다 고유 키를 생성할 때 사용할 수 있다.

 

4. Cipher 스펙 변경. 서버는 가진이 가진 공개키로 브라우저가 보낸 pre-master key를 복호화하여 얻는다.

5. 브라우저와 서버는 이제 각자 pre-master key를 암호화하여 자신들만이 사용할 수 있는 비밀 키로 만든다.

6. 이로써 브라우저와 서버 둘 다 사용할 공유 비밀을 생성하게 되었고, ping pong 테스트 후 둘 사이의 데이터는 남은 세션 기간 동안 보호받는다.

   

 

🚀 HTTPS, SSL 및 TLS의 차이점

 

http는 브라우저와 웹 서버가 소통하기 위한 프로토콜이고 https는 여기에 SSL/TLS로 암호화된 프로토콜이다.

여기에는 이견이 없다.

그런데 이 SSL, TLS라는 녀석들이 무엇인지 알아보았다.
SSL은 'Secure Sockets Layer'의 약어, TLS는 'Transport Layer Security'의 약어
SSL 프로토콜 기술의 제어권이 넷스케이프에서 IETF로 넘어가면서 이름이 바뀐 것 뿐이다.

SSL 3.1 = TLS 1.0 이고, 2018년 TLS 1.3 버전이 나왔다.

SSL 프로토콜은 deprecated 되었고(그렇게 알아두자. 이제 TLS의 시대니까)
TLS는 IETF에 의해유지, 관리되는 프로토콜이다.

 

 

🚀 그래서 https를 어떻게 적용하는데?

 

- AWS ACM을 이용하여 다는 방법은 아래 참고

AWS Certificate Manager(ACM)를 이용 SSL 인증서 등록 및 ELB를 이용한 https force redirection

- let's encrypt를 이용하는 방법은 다른 포스트에서 다루겠다.

 

 

참고하면 좋은 글)

 

howhttps.works/ko/

How HTTPS works