Deview 2021 - NAVER 암호화 트래픽을 책임지는 HTTPS 플랫폼 기술 - 1. 기술

https://tv.naver.com/v/23651836

NAVER 암호화 트래픽을 책임지는 HTTPS 플랫폼 기술

Naver 암호화 트래픽을 책임지는 https 플랫폼 기술

SSL Termination / PassThrough

• termination : 암호화 트래픽의 연산작업을 대행해주는 기능.
  • back에 있는 서버는 복호화되어 있는 데이터만 처리함.
  • 리소스 효율화 / 백엔드의 외부 노출이 방지되어 보안에 유리한 솔루션.

 

nFront 플랫폼이 오픈하던 시기는 2018년.

• 브라우저가 https를 디폴트 통신으로 설정하는 추세, https 아닐 경우 경고메시지 표시... https 전환에 속도를 내는 상황
• 하지만 모든 부서가 https 사용 -> 리소스 소모 / 인프라 증설 필요. 암호화 트래픽이 늘어나며 보안 감시도 어려워짐.

-> SSL termination 필요성이 커짐

 

리버스 프록시를 활용해서 SSL termination 수행하는 nFront 개발.

1. GSLB로 IDC 이중화, Stateless L4를 앞단에 배치 -> 안정성 확보.
2. 프록시 - 프론트엔드 암호화 처리, back에 복호화된 트래픽 전송
3. 복호화 트래픽은 IDS에 연동 (보안 강화)
4. 서버의 agent - 모니터링 지표 / request log 수집 + 실시간 확인.

현재 Bare Metal + K8s 기반으로 nFront 운영중

 

HAProxy 사용한 이유

• proxy가 추가될 때 가장 낮은 Latency
• 멀티 인증서 운영에 편리
• Zero time Reload
• 모니터링에 필요한 정보를 runtime API로 수집 가능했기 때문

 

• 백엔드 리소스 절감, 성능 향상
• 프록시 서버에만 인증서 배포하면 되므로 관리효율성
• 취약점 대응이 수월하고, 백엔드 서버를 외부로 노출하지 않아 보안에도 용이함
• L7 레이어 기능을 활용할 수 있음.

 

리버스 프록시로 SSL Termination 시 주의점

• 백엔드 서버 입장에서는 요청하는 ip가 proxy IP. 따라서 예컨대 source ip의 rate limit이 걸려 있다면, proxy ip는 white list로 관리해야 한다.
• client ip를 백엔드에 전달하려면 X-Forwarded-for처럼 추가로 헤더에 값을 입력해주고, Remote IP로 변환하는 작업이 필요하다.
  • XFF 헤더는 이미 알려진 헤더값이므로... 보안상 별도의 헤더 세팅이 필요함.
• http로 들어온 요청을 https로 Redirect하는 로직은 직접 처리해야 한다. Origin에서 처리할 경우 redirect loop에 빠질 수 있음.
  • 백엔드 서버 입장에서는 전부 http로 트래픽이 들어오기 때문에, 특정한 헤더값을 통해 프록시에서 http로 들어온 건지 확인해서 처리해야 한다.
• 서버 내의 여러 인증서를 서비스하기 위해... tls Extension인 SNI를 활용할 수 있음.
  • SNI 지원하지 않는 레거시 클라이언트도 지원하려면, 대표 인증서의 SAN에 해당 도메인을 추가하거나 / 해당 도메인은 별도 ip로 분리해 처리하는 것이 좋다.

 

SSL 성능에 영향을 미치는 요인은 매우 많다.

• 성능 향상에만 치우친 설정은 보안에 취약할 수 있음

 

하드웨어 성능 튜닝

1. 네트워크
   • 가능하면 GSLB로 네트워크 상태 / 지리적 위치 고려해서 ip 밸런싱
   • Source hash 기반 Stateless L4 -> 클라이언트가 동일한 서버로 계속 연결될 수 있도록 -> keep-alive 효율
   • 글로벌 거점마다 플랫폼 구축해서 Last Mile을 줄이거나
   • 동적 가속 플랫폼을 활용해도 좋다고 함
2. 하드웨어
   • CPU: 암 / 복호화 성능에 직결됨. 적절한 Affinity 설정으로 latency 줄이기.
   • BIOS power-saving 설정 전부 비활성화하고, 최대성능 낼 수 있도록 세팅
   • NIC 쪽은 슬라이드 하나 더 쓰면서 상세히 설명하는 거 같은데, 못알아듣겠어서 패스

 

커널 튜닝: 대량의 connection 처리를 위한 설정이 필요함. 기본값보다 증가 / 감소, enable / disable해야 할 파라미터가 슬라이드에 쓰여 있다.

여기도 디테일한 내용은 모르겠어서 패스.

 

인증서 / 공개키 성능향상 방법

• 현재 hybrid certificate / 공개키 암호방식은 ECDSA를 기본으로 사용함.
  • ECDSA : 작은 키값으로 우수한 보안효과.
  • RSA : 레거시 환경의 클라이언트 지원용.

 

대칭키 알고리즘은 AES_GCM, CHACHA POLY를 많이 쓴다. 속도 / 보안강도 둘 다 좋은 편

 

TLS handshake 과정 간소화를 위한 Session Resumption.

• 최초 연결에 사용한 암호화 알고리즘은 그대로 사용
• 키 교환과정을 생략해서 handshake를 줄여줌.
• Session ID : 서버에 캐시를 두고, 클라이언트별 세션 id를 저장하는 방식.
  • 각 서버마다 동일한 캐시를 가지고 있는 게 아니라서 Resumption 효율이 떨어짐.
• Session Ticket : 전체 서버에서 동일 key로 티켓 생성해서 클라이언트에 전달
  • 클라이언트는 어떤 서버에 접근해도 Resumption이 가능한 구조.
  • 별도의 캐시를 두지 않으므로 메모리 절약.
  • 브라우저에서 ticket을 지원하지 않을 수 있으므로 session id도 병행하면 좋다.

 

TLS 1.3

• handshake 절차 간소화
• 암호화 모음 단순화 (취약한 Cipher 제외)
• 키 교환을 타원곡선 방식으로 통합
• Zero RTT로 속도를 더 빠르게 가져갈 수 있지만, 보안상 취약해짐

 

OCSP Stapling 사용할 경우

• 브라우저에서 인증서 무결성 체크하는 과정을 서버가 대신함. 따라서 클라이언트 리소스 절약이 가능
• openssl 명령어로 제공여부 체크 가능

http -> https로 Redirect할 때, HSTS header 또는 permanent redirect (301, 307) 등으로 브라우저에 상태를 저장하면 불필요한 redirect를 줄일 수 있다.

• permanent redirect 쓸 때에는 신중해야 함

 

애플리케이션 (HA Proxy) 설정에 참고하면 좋을 정보들

 

모질라 재단에서 제공하는 SSL설정 생성해주는 페이지. config 생성할 때 참고하면 좋을 듯.

 

암 / 복호화 처리를 가속화할 수 있는 기술. 인텔의 하드웨어 기반 QAT를 내부적으로 PoC했었다고 함.

• RSA에서는 우수했지만, ECDSA 성능은 좋지 않은 편이었다고.
• 인텔에 공유하고, 향후 버전에서 개선하겠다는 답변 받음