[TIL] SSL offloading 이란 무엇일까?

---

이번 글에서는 SSL offloading에 대해 알아보도록 하겠습니다.

1. 상황 (KKK 서비스)

A : 저희 이번 신년 기점으로 순간 트랙픽이 튀었었는데. 이부분 관련해서 고민해 보아야 할 게 있어요.  
B : 트래픽 몰릴 것을 대비해서 서버 수도 미리 증설해두었는데도.. 트래픽을 감당하지 못했네요.. 이 문제를 어떻게 해결하면 좋을까요?  
A : 서버 갯수의 문제가 아니였던 것 같아요. 트래픽이 몰린 시점을 보면, 각 서버별 CPU 사용량도 그렇게 높지 않았어요. 인프라쪽에 문의해본결과 트래픽이 처음 인입되는 L4의 QPS에 한계가 있는 것 같다는 답변을 받았습니다. 즉.. 맨 앞단에서 클라이언트 트래픽을 받고 있는 L4가 해당 트래픽을 견디지 못하고 있기 때문에 효과가 없었던 것 같습니다.  
B : 네, 말씀하신게 맞다면. 서버증설등의 노력은 물거품이 되었겠네요.  
A : 맞아요. 그래서 생각해봤는데요. 저희 L4 에서 하고 있는 SSL offloading 을 API Gateway 단으로 내려서 L4의 부하를 줄이는게 어떨까요? L4는 트래픽을 byPass & load balancing 만 하고. ssl offloading 은 API Gateway 단에서 할 수 있도록이요.  
B : 네.. 말씀하신 부분 한번 고민해 보아야 겠네요.

2. SSL

위 에서 언급한 SSL offloading 이란 무엇일까? 왜 SSL offloading 을 한단계 내리면 L4에 부하가 줄 수 있을까?

위에 대해 이해하기 위해선 먼저 'SSL/HTTPS'에 대해 이해할 필요가 있습니다.

링크된 글의 설명과 같이 현대의 통신은 SSL을 사용해 보다 안전하게 통신할 수 있습니다. 하지만 SSL 통신을 위해 초기 Client 와 Server 사이에는 SSL handshaking 이라는 일련의 '상호 확인' 작업? 을 하게 되는데. 이 작업이 생각보다 많은 resource 를 사용하게 됩니다.

자세한 SSL handshaking의 단계는 다음과 같습니다.

1) 클라이언트가 서버에 "ClientHello" 메세지를 전송합니다.

이때 클라이언트는

1-1) SSL/TLS version
1-2) SSL 통신에 사용할 암호 알고리즘
1-3) 데이터 압축 방법 (ex Gzip)

등의 정보를 함께 전송합니다.

2) 서버가 클라이언트에 "ServerHello" 메세지를 전송합니다.

서버는 클라이언트가 전송한 데이터를 확인하고. 그에 따른 응답으로

2-1) 클라이언트가 요청한 암호 알고리즘의 대한 동의
2-2) 서버에서 생성한 SessionID
2-3) 서버의 digital certificate
2-4) 서버의 public key

를 보내주게 됩니다.

3) 클라이언트는 서버가 보내온 digital cetificate 를 확인해 신뢰할 수 있는 서버인지 확인합니다.

클라이언트는 서버가 보내온 digital certificate를 공인 CA에 확인합니다.

이후 정상적으로 서버가 신뢰하다고 판단되면

다음의 단계를 거치게 됩니다.

4) 클라이언트는 서버에 통신에 사용할 shared secret key 를 전송합니다.

shared secret key 는 서버와 클라이언트 각각 하나씩 소유하게 됩니다. (동일한 키)

이 때 shared secret key 는 서버가 전송해온 public key 로 encrpty 되어 전송됩니다.

5) 클라이언트가 서버에 Finish 메세지를 보냅니다.

SSL handshaking 의 완료를 의미하는 메세지는 shared secret key 로 encrtpy 해 전송하며.

이를 통해 클라이언트의 SSL handshaking 이 완료되었다는 것을 서버측에 알려주게 됩니다.

6) 서버도 클라이언트에게 Finish 메세지를 보냅니다.

동일하게 서버도 SSL handshaking 완료 메세지를 shared secret key 로 encrpty 해 전송합니다.

7) 이제 서버와 클라이언트는 각각 소유한 shared secret key 를 사용해 암호화된 통신을 하게 됩니다.

위와 같이 SSL 통신을 하기 위해선 서버와 클라이언트 사이에 알게 모르게 많은 과정을 거치게 되는데.

때문에 위와 같은 작업을 API 를 Serving 하는 서버에서 직접하게 되면 서버에 부하가 가중되게 됩니다.

( 예를 들어 가수가 노래를 해야되는데.. 방송사랑 일정 조율하고.. 출연료 협의하고 이런일들을 하느라.. 노래부를 힘을 낭비한다고 할까나..? )

3. SSL offloading

그래서 대부분의 서비스의 경우 API 서버군 앞에 Proxy 서버를 두고 해당 Proxy 서버에 SSL 관련 작업을 위임합니다.

이 때 Proxy 서버(소속사 or 매니저)는 일반적인 서버보다 SSL encrpty/decrpty에 성능이 좋은 장치를 사용합니다.

Proxy 서버를 거친 데이터는 decrpty 되어 HTTP 통신을 하게 되므로. HTTPS를 사용해 통신하는 것 보다 빠른 속도로 통신하게 됩니다.

이때 Proxy 서버와 내부 서버간의 internal traffic 은 방화벽 등으로 안전하게 보호된다고 가정합니다.

이를 통해 웹 서버가 본인들의 역할 (노래부르기) 에 집중할 수 있게 됨으로써 사용자 (클라이언트) 입장에서는 조금 더 쾌적한 환경의 서비스를 이용할 수 있게 되는 것 입니다.

위와 같은 전략을 일반적으로 SSL offloading 이라고 부르며. 이를 통한 이점은 다음과 같습니다.

1) 웹 서버가 더이상 SSL encrpty/decrpty 에 신경쓰지 않게 되어 해당 resource 를 다른 작업에 사용할 수 있게 됩니다.
2) 웹 서버의 속도를 높여줌으로써 사용중인 웹 서버의 수를 늘리지 않고 웹사이트가 클라이언트의 요청을 더욱 잘 처리할 수 있게 됩니다.

하지만.. 만약에 공격자가 Proxy 서버에 접근할 수 있게된 경우 모든 data 가 decrpty 되어 노출 될 수 있습니다.

4. 그래서 결론이 뭔데?

앞선 A와 B의 대화에서 'KKK 서비스'가 L4의 QPS 한계로 인해 순간 트래픽을 감당하지 못하고 있음을 확인했습니다.

현재 'KKK 서비스'는 L4가 트래픽의 맨 앞단에서 Server 군을 대신해 Load Balncing과 동시에 SSL handshaking 작업을 하고 있는데요.

1) 현재 (L4가 SSL handshaking 을 담당하는 Proxy 서버의 역할을 수행함)

SSL handshaking 작업이 resource 를 많이 잡아먹으므로.. 해당 작업을 한단계 내려서 L4에 부하를 줄이면 조금더 많은 트래픽을 감당할 수 있지 않을까? 라는 의견입니다.

물론, L4 바로 아래단에 위치한 API Gateway 가 해당 부하를 받아들이지 못한다면. 말짱 도루묵입니다.

또한 하나의 L4에서 관리하던 digital certificate 를 각각의 API Gateway 서버에서 관리해야 되는 번거로움도 고민해야봐야 할 이슈입니다.

2) 변경 후 (API Gateway가 SSL handshaking 을 담당하는 Proxy 서버의 역할을 수행함)

참고자료 : https://www.youtube.com/watch?v=H0bkLsUe3no

---