HTTPS Interception Proxy

해당 내용은..HTTPS 패킷을 장비를 통해 분석할 때

   

HTTP의 보안이 적용된 것으로 HTTPS는….

   

Secure Sockets Layer (SSL)

Transport Layer Security (TLS)

   

TLS는 SSL이 표준화가 되면서 바뀐 이름이다.

최신 RFC는 1.2 버전으로 https://tools.ietf.org/html/rfc5246 여기서 확인할 수 있다.

   

   

   

SSL, TLS에서의 인증 방식을 그림으로 나타내면 위와 같다.

   

이는 서버와 클라이언트가 보안키를 주고 받아야 하기 때문에 이러한 패킷을 까서 Application Data(Plain Text)를 보기에는 어려움이 따른다.

   

그래서 중간에 Interception Proxy를 이용해 두 교환 포인트(클라이언트<->Proxy<->서버) 를 만들어 이를 가능하게 할 수 있다.

   

결국 하나의 세션을 두 세션으로 분할하여 중간자 공격(MITM:Man in the Middle) 형태로 갈 수 밖에 없다.

이는 DPI(Deep Packet Inspection), 차세대 방화벽, 어플리케이션 인식 방화벽, DLP(Data Loss Prevention) 시스템 등 전부 위와 같은 중간자 공격 형태로 이루어진다.

   

클라이언트방향의 SSL 세션을 만들기 위해서는 interception proxy는 제시된 인증서에 해당하는 private key에 대한 접속이 가능해야 합니다.

   

또한 Proxy는 서버 endpoint의 개인키(private key)를 사용할 수 없기 때문에 Interception Proxy는 새로운 인증서와 키를 생성해야 한다.

 

이 인증서는 CA(인증기권) 에 의해 서명되어야 한다. 그렇지 않으면 에러가 발생하게 된다.

   

Private CA

더욱 일반적인 시나리오는 프록시의 사용을 위해 사설 인증기관(private CA)를 생성하는 것이다.

이 방법은 적절하게 구성된 클라이언트 endpoint로부터의 에러를 방지한다.

   

Public SubCA

신뢰할 수 있는 루트 기관으로부터 권한을 부여 받은 중간 서명기관.

interception proxy 의 용도로 인증서를 사용하기 위해 신뢰할 수 있는 루트 인증기관을 설득하여야 합니다.

이 방법은 엔드포인트가 신뢰할 수 있는 루트기관에 대한 인증서를 이미 신뢰하기 때문에 배포 프로세스를 손쉽게 도와줍니다.

   

   

이러한 interception proxy에 대한 위험

법적 노출

   

이러한 보안 프로토콜을 까보는 것은 법적으로 문제가 될 가능성이 높다. 암호화된 프로토콜을 열어서 개인정보를 확인하는 것은 고용주의 권리와 의무에 영향을 끼칠 수도 있다.

Microsoft의 forefront threat management gateway HTTP interception 기능에도 아래와 같이 법적 위험을 고지하고 있다.

   

   

표면적 위험 증가

Interception Proxy는 결국 암호화된 트래픽을 풀어서 plain-text를 조사하는 것으로 암호화된 트래픽은 종종 공격자들에 의해 높은 가치로 평가된다.

   

그러므로, plain-text로 볼 수 있는 단일지점을 제공하는 것은 공격자들에 의해 높은 타겟이 될 수 있다.

Interception Proxy를 공격하는 것은 그들에게 이러한 plain-text를 제공하고 이를 수정할 수도 있는 기회를 줄 수도 있다.

   

그러므로 인증기관은은 client endpoint에 의해 신뢰받는 지점이기 때문에, 공격자에게는 매우 높은 가치의 목표지점이다.

만약 인증기관의 서명된 키가 손상된 경우에는 client endpoint에게 Spoof(패킷을 속이는) 공격이 가능하다.

   

SubCA를 사용하는 interception proxy는 서명된 키의 노출 위험이 더 커진다. 이 위험은 해당하는 루트를 신뢰하는 인터넷의 모든 client endpoint로 확장됩니다. 마찬가지로 생성된 개인 키의 노출은 유효한 웹사이트에서의 스푸핑 공격이 가능하게 됩니다.

   

암호화 수준의 감소

두 지점(point-to-point)간의 암호화 세션에서 발생하게 되는 이슈로, 각각의 세션에서 cipher suite를 독립적으로 협상하는데 클라이언트측이나 서버측에서 직접 세션보다 약한 암호화 세션을 사용할 가능성이 있다.

   

예를들어 google의 웹 속성(properties)를 포함하는 세션을 고려해보면 구글은 최근 forward secrecy를 지원하는 cipher suite를 선호하는 쪽으로 움직이고 있다.

   

Forward secrecy(PFS:perfect forward secrecy)는 특정 cipher suite의 암호화 방식이다.

이는 전송중에 사용되는 암호화된 데이터에 사용되는 또 다른 키로부터 endpoint의 키로 사용하여 노출의 위험을 감소시킨다.

두번째 키는 짧은 시간과 하나의 세션에 대해서만 사용한다.

   

이러한 프로세스의 결과로 서버의 private key가 손상(compromised)되면 이전에 생성된 컨텐츠들은 복호화 될 수 없을 것이다.

높은 보안 수준 환경에서 이 속성은 공격자가 나중에 키 복구의 기대와 많은 암호화 텍스트 수집의 가능성에 대한 방지책으로 볼 수 있다.

   

많은 경우에 가치가 있는 PFS를 지원하는 cipher suite은 성능과 구현의 복잡성 때문에 일반적으로 선호가 되지는 않는다.

그 결과로 Proxy는 PFS에 필요한 cipher suites를 지원하지 않을 수 있고, 이 경우, endpoint의 지원에도 불구하고 클라이언트측과 서버측 모두 PFS가 결여된 약한 cipher suites로 돌아갈 수 있다.

   

Forward Secrecy만 좀 더 알아봐야겠네요...