SSL 통신의 세부원리

SSL 은 암호화 통신을 위해 대칭키, 비대칭키 방식을 혼용하여 사용합니다.

이것은 공개키, 개인키를 활용하는 ssh 통신의 원리와 거의 같은 방식입니다.

차이점은 SSL 통신에는 디지털 인증서가 필요하다는 점입니다.

 

SSL 디지털 인증서는 클라이언트가 접속한 서버가 

통신하려고 하는 대상이 맞는지를 제 3자가 보증해주는 전자문서입니다.

 

서버는 CA(Certificate Authority) 기관에게 본인의 신원을 보장해줄 수 있는 인증서를 구입하고 설치하는데

CA 기관은 아무기업이나 참여할 수 없고 신뢰성이 공인된 기업만 이를 수행할 수 있습니다.

(우리나라 공인인증서도 은행은 금융결제원, 증권/보험은 SignKorea 에서만 발급하는 것과 비슷합니다)

 

즉, 공인기관에서 보장하는 인증서를 갖춘 서버와 암호화 통신을 하는게 SSL 통신입니다.

 

SSL 을 이용한 대표적인 통신방식이 웹기반의 https 인데

아래 예를 살펴보면 안전한 웹접속을 위해 Thawte(한국전자인증) 으로 부터 

이 사이트가 우리은행임을 보장하는 ssl 인증서가 설치되어 있고

이를 신뢰해서 https 통신이 이루어지는 것을 확인 할 수 있습니다.

 

<웹 브라우저 주소창의 자물쇠는 https 를 의미합니다>

 

<전단계에서 인증서 항목을 클릭하면 상세정보를 확인할 수 있습니다>

 

 

만약 위와 같은 화면이 나타나지 않고 https 로 접속했는데 아래와 같은 화면이 나타났다면

서버에 인증서는 설치되어 있되, 공인기관의 인증서가 아닌 것입니다.

<일상적으로 사용하는 사이트인데 https 경고가 나타납니다>

 

 

위의 예시를 살펴보면 sectigo 라는 기관에서 *.serii.re.kr 에게 발급된 인증서를 완전히 신뢰할 수 없다는 의미입니다.

 

해당 인증서가 신뢰할 수 있는가를 판단하는 주체는 웹브라우저입니다.

웹브라우저 내부에는 CA 리스트가 담겨있는데 위의 경우는 아쉽게 반영이 되어 있지 않은 것 같네요.

 

웹사이트는 공인된 CA에게 인증서를 발급받으려면 일정요건을 갖추고 서비스 신뢰성을 평가받은 후 비용을 지불해야

해당 CA로 부터 인증서를 발급 받을 수 있습니다.

 

그렇다면 전세계 모든 웹사이트는 몇몇 공인CA 로부터 인증서를 발급받아야만 HTTPS 로 연결 할 수 있을까요?

개발이나 개인적인 목적을 위해서 SSL 통신을 하기위해서는 자신이 직접 CA 역할을 할 수도 있습니다.

물론 이것은 "공인"된 인증서가 아니기 때문에 위와 같이 인증서를 신뢰할 수 없다는 메세지가 나타나게 됩니다.

<그림1> ssl 인증서를 인증할 수 없음

 

위와 같이 안전하지 않음 메세지가 나오더라도

추가 선택으로 웹페이지로 이동을 직접 선택해주면 HTTPS 통신은 이루어집니다.

차이점은 해당사이트를 인증해준 인증서를 신뢰할 수 있느냐 입니다.

 

SSL 인증서에는 해당 사이트 서비스의 정보(인증서를 발급한 CA, 서비스 도메인 등) 와

"서버측 공개키"가 들어있습니다.

 

서버측 공개키는 CA의 비공개키(비밀키)를 이용해서 암호화 되어 있습니다.

즉 CA의 공개키로 누구나 복호화 할 수 있는 것입니다.

 

 

 

앞서 말했듯이 SSL 의 암호화 통신 원리는 SSH 와 비슷합니다.

 

1. 클라이언트가 서버로 접속함

1-1. 클라이언트가 랜덤값을 생성하고 서버로 전달함

1-2. 클라이언트는 자신이 사용할 수 있는 암호화 방식을 전달함

1-3. 세션값을 전달함(처음 연결때는 빈값, 재접속일때는 기존 세션ID)

 

2. 서버가 클라이언트에게 응답함.

2-1. 서버도 랜덤값을 생성하고 전달함.

2-2. 클라이언트가 보내온 암호화 방식 중 하나를 선택해서 클라이언트에게 전달함

2-3. 인증서를 전달함.

 

3-1. 클라이언트는 자신이 보유한 CA 리스트에서 서버 인증서를 발급한 것인지를 확인함

  (해당하지 않으면 <그림1> 의 메세지가 발생)

 

3-2. 클라이언트는 인증서가 CA 에서 발급한게 맞는지 확인하기 위해 CA 공개키로 복화화함

      복호화가 성공했다면 CA가 보증하는 문서가 맞고, 해당 인증서를 전송한 서버를 신뢰할 수 있다고 판단함.

 

4. 클라이언트는 자신의 랜덤값과 서버로부터 받은 랜덤값을 조합해서 pre-master secret 값을 생성함

   pre-master secret 값은 추후 데이터 전송시 대칭키 값으로 사용하게 됨

 

5. pre-master secret 값을 안전하게 전달하기 위해 비대칭키 방식으로 상호 전송

5-1. 클라이언트는 서버 공개키로 pre-master secret 를 암호화해서 서버로 전송

5-2. 서버 공개키는 이미 전달받은 인증서에 포함되어 있음.

 

6. 서버와 클라이언트는 pre-master secret 값을 공유하게 되었음.

   서버와 클라이언트는 이를 master secret 값으로 변환함.

 

7. master secret 을 이용해 세션키를 생성하고 이를 대칭키로 활용하여 데이터를 전송함

 

8. 세션이 끝나면 통신에서 사용한 대칭키를 폐기함.

 

 

[참고자료]

 

https://opentutorials.org/course/228/4894

HTTPS와 SSL 인증서 - 생활코딩

 

https://reakwon.tistory.com/106

[네트워크/보안] TLS(SSL) 개념과 기본 동작 원리