Apache : MITM 공격을 방지하기 위해 SSL 신뢰 체인을 검증합니까?


11

방금 SSL 기업 간 공격이 생각보다 훨씬 일반적이라는 사실을 깨달았습니다. 특히 기업 환경에서는 더욱 그렇습니다. 투명한 SSL 프록시 서버가있는 여러 기업에 대해 들었습니다. 모든 클라이언트는이 프록시의 인증서를 신뢰하도록 구성되어 있습니다. 이것은 기본적으로 사용자가 브라우저에서 경고 메시지없이 SSL 암호화 된 트래픽조차도 이론적으로 가로 챌 수 있음을 의미합니다. 위에서 언급했듯이 클라이언트는 신뢰할 수있는 인증서와 함께 제공됩니다. 이것은 사용중인 인증서를 수동으로 확인해야만 알 수 있습니다.

나에게 그것은 고용주가 직원의 SSL 트래픽을 감시하기 위해 자신의 우월한 위치를 이용하는 것처럼 보입니다. 나에게 이것은 SSL의 전체 개념을 신뢰할 수 없게 만듭니다. mitmproxy를 사용하여 비슷한 설정을 성공적으로 테스트했으며 클라이언트와 전자 뱅킹 서버 간의 통신을 읽을 수있었습니다. 이것은 누구에게도 공개해서는 안되는 정보입니다.

따라서 내 질문은 다소 간단합니다. 서버 쪽에서 신뢰 체인을 어떻게 확인할 수 있습니까? 클라이언트가 내 서버의 인증서와 하나의 신뢰 체인 만 사용하고 싶습니다. 이것이 Apache의 SSL 구성으로 달성 될 수 있는지 궁금합니다. 많은 응용 프로그램에 쉽게 적용 할 수 있으므로 편리합니다. 이것이 가능하지 않다면 PHP로 이것을 수행하는 방법을 아는 사람이 있습니까? 아니면 다른 제안이 있습니까?


1
고용주가 직원의 트래픽을 보는 것이 괜찮습니다. 귀하는 고용주의 자원 (PC, 네트워크 연결 등)을 사용하고 있으며 귀하의 자원이 아닙니다. 그리고 만약 빈민이 은행 계좌로 전송 한 데이터를 볼 수 있다고 걱정한다면 직장에서가 아니라 집에서하십시오. 그리고 회사 보안 정책을 위반하려는 시도는 귀하를 상대로 한 법원의 대상이 될 수 있습니다.
Crypt32 2016 년

2
많은 유럽 회사에서 개인 계약 사무 장비 사용은 고용 계약에서 규제됩니다. 내가 일하는 회사에서 나는 개인적으로 서핑을 할 수도 있지만 그것은 문제가되지 않습니다. 포르노, 파일 공유 등과 같은 예외가 있습니다. 동시에 회사가 직원을 감시하는 것을 금지하는 법률이 있습니다. 따라서 많은 회사에서 개인 서핑이 허용되는 동안 고용주가 직원 트래픽을 가로채는 것은 분명하지 않습니다.
Aileron79

2
(내 경험상) 미국 정부 소유의 워크 스테이션은 대부분 로그인 할 때마다 다음 두 가지 통지를 포함합니다. 이 IS는 개인의 이익이나 프라이버시가 아닌 USG의 이익을 보호하기위한 보안 조치 (예 : 인증 및 액세스 제어)를 포함합니다. " 이러한 시스템의 사용에는 종종 동일한 내용의 서명 된 계약이 적용됩니다. 핵심 세부 사항은 시스템 소유자가 자신을 보호하고 있다는 것입니다.
랜달

그것은 미국과 유럽의 많은 차이점 중 하나입니다. 위에서 인용 된 @Randall이라는 용어는 대부분의 유럽 국가에서 불법입니다.
Aileron79

내가 인용 한 용어는 불완전하고 다른 용어는 명시 적으로 모니터링하지 않는 활동을 나열합니다. 유럽 ​​고용주가 그러한 전제 조건을 자신의 컴퓨터를 사용하는 조건으로 만들 수 없다고 언급 한 자료를 찾을 수 없습니다. 유럽), 그러나 그러한 용어가 명백하고 투명하기 만하다면 이러한 용어가 불법이 아님을 암시하는 참조를 찾을 수 있습니다.
랜달

답변:


9

MITM의 주제가 많은 질문에서 논의되는 security.stackexchange.com 에이 질문이 더 적합 할 것이라고 생각합니다 . 그러나 어쨌든 :

서버 인증서의 유효성 검사는 클라이언트에서만 수행되며 클라이언트에서 인증서의 유효성을 검사하는 지점은 클라이언트가 올바른 서버와 통신하고 있으며 신뢰할 수 없는지 확인해야하기 때문에 서버로 이동할 수 없습니다. (신뢰할 수없는) 서버가 클라이언트에 대해이 결정을 내립니다.

SSL 차단의 경우 서버 관점에서 TLS 클라이언트는 SSL 차단 방화벽 / AV입니다. 따라서 서버 측의 문제는 클라이언트가 예상 클라이언트 (브라우저)와 통신하는지 (방화벽 / AV) 여부를 감지하는 것입니다. 이를 수행하는 가장 안전한 방법은 클라이언트 인증서를 사용하여 클라이언트를 인증하는 것입니다. 실제로 클라이언트 인증이 사용되는 경우 SSL 차단이 작동하지 않습니다. 즉 MITM이 예상되는 클라이언트 인증서를 제공 할 수 없으므로 TLS 핸드 셰이크가 실패합니다.

클라이언트 인증서 만 사용되는 경우는 거의 없습니다. 또한, TLS 핸드 셰이크 실패는 클라이언트가 SSL 차단없이 서버와 통신 할 수있는 것이 아니라 클라이언트가 서버와 전혀 통신 할 수 없음을 의미합니다. 다른 방법은 일부 휴리스틱을 사용하여 TLS 핸드 셰이크의 지문 (예 : 암호의 종류 및 순서, 특정 확장명 사용)을 기반으로 TLS 클라이언트의 종류를 감지하는 것입니다. SSL 가로 채기 프록시는 이론적으로 원본을 에뮬레이션 할 수 있습니다. ClientHello는 완벽하지 않습니다. 참조 감지 중간자 HTTPS에 대한 서버 측 또는 섹션 III TLS 구현 휴리스틱 에서 HTTPS 차단의 보안 영향 .


14

나에게 그것은 고용주가 직원의 SSL 트래픽을 감시하기 위해 자신의 우월한 위치를 이용하는 것처럼 보입니다. 나를 위해 이것은 SSL의 전체 개념을 신뢰할 수 없게 만듭니다.

문제는 SSL 개념 이나 기술 구현에있는 것이 아니라 다른 사람이 연결의 한 끝점 (예 : 워크 스테이션)을 완전히 제어 할 수 있다는 것입니다.
이것이 실제 보안 위험의 근본입니다 ...

보안 측면에서 타협 된 워크 스테이션은 정상적인 상황에서 MITM의 성공을 방해하는 신뢰 체인을 깨뜨립니다.

서버 측에서 신뢰 체인을 어떻게 확인할 수 있습니까?

당신은 할 수 없습니다. 그것은 클라이언트 측에서 이루어집니다.

사용 사례에 따라 RFC 7469 HTTP 공개 키 고정 은 실제 SSL 인증서 또는 사용하는 CA의 목록 (해시)과 함께 추가 헤더를 클라이언트에 보냈습니다.


4
인증서가 명시 적으로 추가 된 CA에 의해 서명 된 경우 HPKP는 브라우저에서 무시되므로 도움이되지 않습니다. 이는 특히 회사 방화벽 또는 로컬 데스크톱 AV (다수의 SSL 차단 수행)와 같은 신뢰할 수있는 당사자의 SSL 차단을 허용하기 위해 수행됩니다.
Steffen Ullrich

2
RFC의 §2.6 : "로컬 정책에 따라 일부 호스트에 대해 핀 유효성 검사를 비활성화 할 수 있습니다. 예를 들어 UA는 확인 된 인증서 체인이 다음 위치에있는 고정 된 호스트에 대해 핀 유효성 검사를 비활성화 할 수 있습니다. "UA (또는 기본 플랫폼)에 내장 된 신뢰 앵커가 아닌 사용자 정의 신뢰 앵커"
HBruijn

3

그게 잘못된 방법입니다. 서버가 신뢰 체인을 확인하지 않습니다. 클라이언트입니다. 따라서 회사가이 방법을 사용하는 이유는 회사 환경을 보호하고 직원이 근무 시간에 무엇을하고 있는지 확인하는 것입니다.


글쎄, 나는 이것이 아마도 서버 측에서만 예방할 수 없다는 것을 알고 있습니다. 그러나 일부 클라이언트 측 JS도 속일 수 있습니다. BTW, 직원에 대한 감시는 대부분의 유럽 국가에서 불법입니다. 웹 사이트 운영자로서 고객이 속지 않도록하기 위해 안전한 방법으로 신뢰 체인을 검증 할 수있는 방법이 있는지 궁금합니다.
Aileron79

어쩌면 허용되지 않을 수 있습니다. 그러나 대부분의 회사는 회사 네트워크 만 보호하려는 직원을 감시하지 않으며 대부분의 웹 필터 또는 스캐너는이를 확인하기 위해 SSL 연결을 끊어야합니다. 중간 공격에 합법적 인 사람입니다
beli3ver

나는 당신의 요점을 이해합니다. 그러나이 질문은 HTTPS 연결이 종단 간 암호화되도록하는 방법에 관한 것입니다. 위에서 설명한 설정은 회사 환경에서 매우 일반적이지만 질투심 많은 소년이 여자 친구를 감시하거나 집주인이 세입자의 트래픽을 가로 채기 위해 동일한 종류의 공격을 사용할 수 있습니다. 이 사람들은 여전히 ​​인증서 설치에 속지 않아도되지만 쉬운 부분입니다. 그러나 이것은 불법입니다. HTTPS 연결이 실제로 e2e로 암호화되도록 할 수있는 방법이 있는지 궁금합니다.
Aileron79

3
그건 불가능하다. 클라이언트에서 루트 인증서가 변경된 경우 확인할 방법이 없습니다. 서버가 확인하지 않고 클라이언트가 확인합니다.
beli3ver

3

당신은 (종류),하지만 당신은 여부를 진짜 질문은 SHOULD .

그러나 apache.conf에서 플래그를 변경하는 것만 큼 간단하지는 않습니다.

또한 "공격자"(예 : 고용주)가 클라이언트 컴퓨터를 제어 할 때 충분한 노력을 기울이려는 경향이있는 경우 항상 시도 를 방해 할 수 있습니다. 기울어 지므로 사용자가 안전하지 않으면 사용자가 귀하에게 연결할 수 없다는 목표를 달성하게됩니다.)

  • 당신은 수있는 자바 스크립트 TLS를 재 구현 하고 클라이언트가 연결되어있는 인증서가 웹 사이트의 인증서가있는 경우 귀하의 확인을한다.

  • 경우에 당신은 운이 , 사용자는 브라우저 사용하고있는 클라이언트 측 자바 스크립트가 사용되는 원격 인증서에 대한 정보를 얻을 (따라서 쉽게 서버 인증서의 하드 코딩 된 값에 대해 그것을 확인) 할 수 있습니다.

  • JavaScript를 사용 하여 사용자 정의 암호화 를 실행할 수 있습니다 . 따라서 회사의 사악한 TLS MiTM이 성공하더라도 여전히 데이터에 액세스 할 수 없습니다. 물론, 충분히 관심이 있고 (그리고 그들이 클라이언트를 제어하기 때문에), 보안 자바 스크립트를 자신의 것으로 바꾸는 것만으로도 전송중인 모든 정보를 기록 (또는 변경) 할 수 있습니다.

또한 TLS MiTM 프록시를 사용하는 기업은 일반적으로 클라이언트 컴퓨터를 완벽하게 제어하기 때문에 화면과 키로거를 쉽게 설치하여 사용자가 보는 모든 비디오를 녹화하고 사용자가 입력 한 모든 키 입력 (및 마우스 움직임)을 간단히 기록 할 수 있습니다. 당신이 볼 수 있듯이 공격자가 때, IS 클라이언트가 그를 바보 할 절대적으로 안전한 방법이 없습니다. 그것은 그들이 얼마나 귀찮게 할 것인가에 대한 질문 일뿐입니다 ... 그리고 위의 해결책 중 일부는 당신에게 충분할 것입니다.


" 자바 스크립트에서 TLS를 다시 구현할 수 있습니다. "어떻게? 어디?
curiousguy

텍스트 qouted @curiousguy는 링크입니다-그것을 클릭하면 다른 질문과 답변으로 이어질 것이며 마지막으로 digitalbazaar / Forge project
Matija Nalis

언제 사용할 수 있습니까? 어떤 목적으로?
curiousguy

@curiousguy 많은 것들 중에서, 특히이 Serverfault 질문에서 목적을 위해. 클라이언트에서 자신의 JS TLS를 실행하는 경우 해당 클라이언트 JS는 클라이언트가 연결된 TLS 서버 (및 공개 키)를 정확히 알게됩니다. 그런 다음 해당 공개 키를 권한이 부여 된 서버 공개 키 (JS에도 하드 코드 된)와 비교할 수 있으며 이들이 동일한 지 알 수 있습니다. 동일하지 않은 경우 MiTM에서 연결을 도용 한 것입니다.
Matija Nalis
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.