gRPC SSL/TLS 2. SSL/TLS 에 대하여

개요

 

 

1) 앞에서 기반이 되는 암호에 대해 간단히 흝어보았고

2) 여기서는 SSL/TLS 의 동작 원리를 이해하고

3) 마지막으로 gRPC 에서 SSL/TLS 를 어떻게 다루면 될 지 알아보려 한다.

* handshake 는 gRPC 가 알아서 다 해준다.

 

HTTPS 에서 어떻게 암호화를 이루어 내는지를 차근히 따라가보자.

클라이언트 (= 웹 브라우저)가 서버에 접근하여 둘 간의 안전한 암호 통신 세션을 만드는 것이다.

- 세세하고 정확한 설명보다는 큰 그림으로서 개념 설명을 하려 하였으나 수정이 필요한 부분을 알려주시면 고치겠습니다.

 

참고

 

핸드셰이킹과 관련한 어마어마 자세한 링크 2개. 이것보다 더 세세하게 설명할 수는 없겠다.

- https://tls.ulfheim.net/

- https://tls13.ulfheim.net/

 

X509 v3 정보: https://www.lesstif.com/pages/viewpage.action?pageId=7635159

 

 

클라이언트가 서버에 접근하기도 전에 이루어지는 것들

 

1) CA 와 서버 - 서버의 인증서 받기

 

CA 는 Certificate Authority 의 약자이며 인증서를 만들어주는 인증기관이다.

이런 CA (trusted Root CA) 가 필요한 이유는 무얼까?

만약 가짜 국민은행 사이트가 가짜 인증서, 혹은 가짜 공개키를 주며 자신이 국민은행이라고 우기더라도, CA 를 통해 진위를 알아낼 수 있는 것이다.

 

1) 서버는 공개키와 개인키 쌍을 생성한 다음, 인증기관에게 서버 정보 + 공개키 제출

2) 인증기관은 검증 완료후 제출 받은 서버 정보 + 공개키를 인증기관의 개인키로 암호화(= 서버 인증서)

3) 인증기관은 사이트에게 서버 인증서를 줌

-  서버 인증서를 복호화 하려면  인증기관의 공개키가 필요하다.

- 인증기관의 공개키로 복호화가 된다는 것은, 인증기관이 서버를 면밀히 검토했고, 보증한다는 것이다.

- 따라서, 서버 인증서를 복호화 하면 인증기관이 보증하는 서버의 정보와 서버의 공개키를 가지게 된다.

 

2) CA 와 클라이언트 (웹 브라우저) - 웹브라우저는 어떻게 CA 의 공개키를 가지는가

 

인증기관은 사용자가 쓰는 웹브라우저에 인증기관의 공개키를 제공한다.

우리가 크롬, 파이어폭스, 익스플로러를 설치하면, 애초에 검증된 인증기관의 공개키를 가지고 있는 것이다.

- 좀더 심화해서 보려면 아래 링크를 통해 인증서 체인을 알아보자

- https://ibm.co/2XDEozs

- https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/

간략히 설명해본다.

1) 서버는 Intermediate CA 로부터 인증서를 받는데

2)  Intermediate CA 에 대한 공개키는 브라우저에 없을 수 있다.

3)  Intermediate CA 는

- 인증서를 요청한 서버에게 자신이 발급해주는 인증서와 함께

- Root CA 가  Intermediate CA 를 인증해주는 인증서를 보내주는 것이다. 물론 이건 여러 개의  Intermediate CA 를 거쳐서 Root CA 까지 올라갈 수 있다. (Chain)

-  Intermediate CA 는 Root CA 에 의해서 공인된 기관이고,  Intermediate CA 는 해당 서버를 인증해준다는 것이다. 

클라이언트가 서버에 접근하며 이루어지는 핸드셰이킹

 

서버와 클라이언트가 가지고 있는 것들

 

현시점, 서버와 클라이언트가 가지고 있는 것들 부터 생각해보자.

 

클라이언트 (브라우저)	서버
인증기관의 공개키 (브라우저에 기본내장)	서버의 개인키 인증기관이 보증하는 서버 인증서 - 서버의 정보와 서버의 공개키가 암호화되어 담겨있다.

 

 

서버와 클라이언트의 핸드셰이킹

 

서로 데이터를 주고받으면서 암호화된 세션을 만드는 과정이다.

좀 더 쉽게 표현하면 서버와 클라이언트가 공유할 수 있는 대칭 알고리즘의 비밀키를 안전하게 나눠 가지는 것이다.

 

아래 링크는 매우 디테일한 핸드셰이킹 과정이다.

- https://tls.ulfheim.net/

- https://tls13.ulfheim.net/

 

간략하게 과정을 정리해보자

 

1) 클라이언트 (웹브라우저) 사이트에 접속 2) 서버는 인증기관에게서 받은 서버 인증서를 보냄 3) 클라이언트는 인증기관이 웹브라우저에 넣어둔 인증기관의 공개키로 사이트 인증서를 푼다. - 클라이언트는 인터넷 사이트의 서버 정보 + 공개키를 가지게 된다. 4) 클라이언트는 대칭 알고리즘 비밀키를 서버의 공개키로 암호화 하여 사이트로 전송한다. - 이 과정은 엄밀하게는 맞지 않지만 개념만 이해하자 5) 사이트는 암호화된 패킷을 서버의 개인키로 풀어서 대칭 알고리즘 비밀키를 알아낸다. 6) 서버와 클라이언트는 둘만의 대칭 알고리즘 비밀키를 가지게 된다.

 

이제 이걸로 암호화해서 전송하면 받는 쪽에서 복호화해서 풀 수 있는 것이다.

 

인증서 포맷 x.509 v3

 

위키 링크: https://www.wikiwand.com/en/X.509

 

별거 아니다.

인증기관 (CA) 가 만들어주는 인증서의 포맷이다.

 

구글의 인증서를  받아보았다.

1) 크롬으로 www.google.com 으로 접속한 다음에 주소창 왼쪽의 자물쇠 아이콘을 클릭하면 인증서를 볼 수 있다.\

2) 이렇게 볼 수 있는 건, 크롬 브라우저가 이미 가지고 있던 인증기관 공개키로 인증서를 Verify 했다는 것을 의미한다.

 

구글 인증서

- 버전 정보는 X.509 의 버전이 V3 이라는 것 - 시리얼 넘버는 인증기관이 발급한 인증서에 붙이는 번호 - 서명에 쓰인 알고리즘 - 인증서 내용을 SHA256 으로 해싱하고 - 해시값을 RSA 을 이용해 인증기관 개인키로 암호화했다는 것 - 발급한 인증기관 이름 - 유효기간의 시작과 끝: 구글 인증서를 보면 대략 3개월이 안된다. - 주체 (Subject), 즉 서버의 이름이다. - 그리고 드디어 중요한 주체의 공개키 정보 - 공캐키 - 공개키 알고리즘:  ECDSA_P256 (비대칭키 알고리즘) - (중략) - 인증서의 서명 - 원본 메시지와 서명이 있으니 - 브라우저가 기본으로 가지고 있는 CA 공개키를 가지고 - 원본 메시지가 정말 CA 인증기관이 발급한 건지 verify 가 가능하다.

 

 

와이어 샤크로 보기

 

링크를 따라해 보았다.

YouTube 링크: https://youtu.be/u4ht-E-Kihk

 

1) 파이어폭스 브라우저를 열고 설정에서 쿠키와 데이터를 깨끗이 지워줌

 

 

2) 와이어샤크를 실행하고, 파이어폭스 브라우저로 www.naver.com 에 접속. 그리고 로그인을 한 다음에 와이어 샤크를 멈춘다.

3) filter 에 ssl 이라고 쳐서 관련한 패킷들만 남김

4) 그리고 Client Hello 라는 메시지를 찾아서 우클릭 후 Follow >> TLS Stream 을 해준다.

 

 

5) 팝업창이 나오는데 그걸 닫으면 우리가 선택한 패킷과 같은 stream 만 필터링해주게 되며 여기에 && ssl 을 적용해주면 좀더 정리할 수 있다.

 

이제 하나씩 챙겨보자.

 

패킷 121

 

클라이언트가 서버 (네이버)에게 먼저 말을 거는거다.

 

1) 임시 마스터 비밀키를 만들기 위한 랜덤값을 보내고

2) 클라이언트가 다룰 수 있는 암호들의 리스트를 보낸다. 서버보고 뭘로 할지 고르라는 것이다.

- 예를 들면 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 라면 대충 RSA 비대칭키, AES128 대칭키, SHA256 해시 알고리즘을 쓸 수 있다는 거

 

 

패킷 130

 

이번엔 서버가 회신을 했다.

 

1) 먼저 역시나 서버측의 랜덤 값을 보내고 (서버와 클라이언트는 각각 자신들의 랜덤값을 주고 받았다)

2) 서버는 클라이언트가 지원하는 암호들 중에서 하나를 골랐다. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

 

 

 

3) 인증서도 있다. 일부만 살펴보아도 위에서 언급한 X.509 V3 포맷이 보인다.

 

- version: v3 이고

- signature 도 있으며

- validity 로  유효기간이 명시되어 있다.

 

 

 

4) 하나만 더 보면 키 교환 방식이 나와있다.

 

- 디퍼헬만 방식으로 하겠다는 것이다.

 

 

패킷 132

 

클라이언트는 CA 공개키로 인증서를 Verify 하였을 것이다.

 

 

 

패킷 134

 

드디어 서버가 클라이언트에게 새로운 세션 티켓을 주었다.

이후의 패킷은 안전하게 암호화가 되어 주고 받게 된다.