도난당한 TLS 검사 CA 키로 녹음된 세션을 복호화할 수 있을까?

“공격자가 프록시의 개인 키를 훔쳤다”는 말은 피해 규모를 결정하는 세부 사항을 빠뜨립니다. 어떤 개인 키였을까요?

TLS를 검사하는 포워드 프록시는 인증 기관 서명 키, 생성된 서버 인증서 키, 실시간 TLS 트래픽 비밀, 세션 재개 자료, 평문을 자체 메모리나 로그에 보관할 수 있습니다. 이들은 서로 다른 자산입니다.

CA 키가 주는 것은 신원 위장 능력

검사 CA를 신뢰하도록 설정된 클라이언트는 인증서 체인의 제약과 클라이언트의 검사 범위 안에서 그 CA 아래 발급된 인증서를 받아들일 수 있습니다. 해당 서명 키를 훔친 사람은 그 제약 안에서 다른 수용 가능한 인증서를 만들 수 있습니다.

이는 심각하지만, 키만으로는 사용자의 연결을 다른 곳으로 돌릴 수 없습니다. 공격자는 쓸 수 있는 가로채기 위치나 클라이언트를 위장한 종단점에 연결시키는 다른 방법도 필요합니다. 추가 인증서 검사를 하는 애플리케이션은 이를 거부할 수 있습니다.

서명 키는 기록 복호화 키가 아니다

인증서로 인증하는 TLS 1.3 핸드셰이크에서 일시적 Diffie–Hellman을 쓰면 인증서는 교환을 인증합니다. 트래픽 키는 별도의 핸드셰이크 비밀에서 유도됩니다. 나중에 CA 서명 키를 얻는다고 해서 그것만으로 녹음에서 과거의 일시적 비밀이 재구성되지는 않습니다.

서버 인증서의 개인 키를 훔치는 것조차 그런 종류의 녹음된 세션에 대한 트래픽 비밀을 얻는 것과 같지 않습니다. 이를 모든 과거 TLS 방식이나 모든 재개 설정에 일반화하지 마세요. 협상된 키 교환과 유출된 자료가 중요합니다.

실행 중인 검사 어플라이언스의 침해는 그 CA 키의 도난보다 훨씬 광범위할 수 있습니다. 어플라이언스는 트래픽을 검사하면서 평문을 다루고, 세션 비밀을 보유하거나 복호화된 내용을 보관할 수 있습니다. 그러한 노출은 별도의 조사가 필요하며 전방 비밀성을 인용해 일축할 수 없습니다.

사고를 정확히 기술하세요

분실된 자료가 서명 키였는지, 종단점 키였는지, 실시간 비밀이었는지, 저장된 평문이었는지, 어플라이언스 자체의 제어권이었는지 기록하세요. 검사 CA를 교체하고 클라이언트 신뢰를 갱신하는 것은 하나의 능력을 다루는 일이며, 복사된 로그를 지우지도, 실시간 트래픽이 읽혔는지를 판정하지도 않습니다. 정확한 키 이름은 모든 비밀을 “SSL 키”라고 부르는 것보다 훨씬 유용한 대응으로 이어집니다.