https에 사용되는 SSL/TLS 인증과정

현재 진행중인 프로젝트에서 nginx를 프론트 서버로도 사용하고 있지만(빌드된 프론트엔드 파일 배포), 추가적으로 백엔드 서버와의 http 통신을 리버스 프록시를 이용해 nginx가 담당해주고 있다.

이렇게하면 SSL/TLS 인증과정을 모두 nginx가 담당하게 되고, 백엔드 서버는 REST API 서버로 사용되며 서비스 처리에만 집중할 수 있게 된다.

이렇게 개발하면서, SSL/TLS 인증과정의 오버헤드가 얼마나 크길래 nginx에게 인증과정을 맡기는것이 더 빠른가? 라는 의문점이 생겼다.

사실 이 오버헤드는 대칭키/비대칭키 암호화 알고리즘 때문에 생기는 것이였는데, 그래서 이 과정에대해 간단하게 정리해보려 한다.

 

SSL/TLS 인증 과정
전체적으로 요약해보면 서버-클라이언트간 비대칭키 암호화 방식을 통해 세션키(대칭키 암호화 방식에 사용할 키)를 공유하고, 이후 데이터 교환이 일어날 때는 세션키를 사용해 대칭키 암호화 방식을 사용합니다.

인증서의 발급

먼저, G라는 기업이 있다. G라는 기업은 해당 기업이 운용하는 서비스에 https 프로토콜을 지원하기 위해, 인증서가 필요하게 되었다.
CA라는 기업은 인증서 발급 전문 기업이다.

1. G라는 기업은 openssl과 같은 키 생성 도구를 이용해 privateKey를 만든다.
2. 해당 privateKey를 이용해 publicKey를 만들어낸다.
3. 만들어낸 publicKey와 CSR(Certificate Signing Request)를 들고 CA라는 기업에 제출한다.(이 때 돈이 필요할수도)
4. CA라는 기업은, CSR정보를 검토한 후 인증서를 발급해준다. 이 인증서에는 G라는 기업이 생성한 공개키와 CA기업의 서명 정보가 포함되어 있다.

디지털 서명이란?

인증서를 발급할 때, CA라는 기업의 서명 정보가 포함되어있다고 했다. 이 서명정보란건 뭘까?

서명 과정

1. 서명을 생성하기위해 메시지를 해싱한다.

2. 해시값을 암호화하기위해 CA기업의 개인키로 암호화한다.

3. 암호화된 해시값을 인증서에 첨부한다.

 

이렇게 생성된 해시값으로, 클라이언트는 메세지를 받고 해싱 과정을 통해 해당 인증서가 위조된 인증서인지 체크할 수 있게 된다.

 

이렇게 인증서 발급 과정이 끝났다. 인증서가 발급되면, G라는 기업의 서비스는 클라이언트가 접속하게되면, 이 인증서를 클라이언트에게 넘겨준다.

인증서의 사용

비대칭키 암호화 방식으로 작동한다.

클라이언트 사이드

1. 클라이언트는 받은 인증서를 CA 기업의 공개키로 복호화한다.(CA라는 기업은 인증서 발급 전문 기업이므로, 해당 기업의 공개키는 브라우저가 이미 갖고 있다.)
2. 복호화한 인증서가 변조되지 않았는지 확인하기위해, 인증서에 포함된 디지털 서명을 CA의 공개키로 복호화한다.
3. 복호화하게 되면, 받은 인증서 데이터에대한 오리지널 해시값을 얻게된다.
4. 받은 인증서를 같은 해싱 방식으로 해시함수를 통해 해시 값을 얻어본다. 이렇게 얻은 해시값과 인증서에서 복호화해 얻은 해시값과 비교해 인증서의 유효성을 검사한다.
5. 유효한 인증서라고 판단되면, 클라이언트는 데이터 교환 때 사용될 세션키를 만든다.(대칭키 방식에 사용됨)
6. 만든 세션키를 인증서에 포함된 G의 공개키를 이용해 암호화한 후, G 서버에 보낸다.

서버 사이드(G 기업)

1. 클라이언트로부터 받은 암호화된 세션키를, G의 개인키를 이용해 복호화한다. 이렇게 되면, 클라이언트와 G 기업은 같은 세션키를 가지게 된다.

-> 이후 이 세션키를 이용해 대칭키 암호화 방식으로 데이터 교환이 일어난다.

이렇게 순서대로 정리해보았는데, 쭉 써놓고 보니 꽤 복잡한 과정이다. 대칭키 암호화 방식은 비대칭키 방식에 비해 굉장히 빠르므로 데이터 교환에 사용된다.
nginx가 이 복잡한 SSL/TSL 암호화를 담당해준다면 백엔드 rest api 서버가 확실히 부담을 덜 수 있을 것이다.