it-swarm-korea.com

"SSL Inspection"을 방지하기 위해 Javascript / Flash가 SSL 연결을 확인할 수 있습니까?

SSL 웹 페이지가 Fiddler 를 통해 디버깅되고 있는지 또는 SSL Proxy 를 통해 진행되고 있는지 확인하고 싶습니다.

그래서 어떤 사람들은

자바 스크립트를 사용하여 SSL을 다시 확인하는 요점은 무엇입니까?

내 목표는 this 답변에 언급 된대로 언제 연결이 타사 가로 채기를 받는지 아는 것입니다. 취약점은 비밀번호가 노출 될 수 있고 사용자 세션도 노출된다는 것입니다. 악성 소프트웨어 또는 회사 IT 정책에 따라 SSL 가로 채기 및 모니터링이 필요한 경우이 모든 것이 가능합니다.

SSL 연결이 인터셉트되면 어떻게해야합니까?

응용 프로그램의 민감도에 따라 2 단계 인증을 사용하는 경우 프로그래밍 방식으로 연결을 차단하거나 웹 사이트의 특정 부분에 대한 액세스를 제한 할 수 있습니다. 해당 키오스크를 사용할 때의 보안 위험을 나타내는 배너 알림을 표시 할 수도 있습니다. 또는 위험을 이해 한 사용자에게 "예외"를 추가 할 수 있습니다.

내 질문 :

Javascript가 CA 체인을 포함한 현재 SSL 인증서 세부 정보를 확인할 수 있습니까?

이것에 접근하는 올바른 방법은 인증서 발급자를보고 나머지 인증서 체인을 보는 것입니다. 다음 단계는 체인의 각 인증서를 나열하고 해당 CA 중 하나가 루트 CA와 공개적으로 신뢰되는 것과 동일한 지 확인하는 것입니다. 사용자가 로컬 컴퓨터에 추가 한 추가 인증서를 구체적으로 제외하고 싶습니다.

Security.stackexchange.com의 사람들이 이에 접근하는 방법에 대한 아이디어를 제공하기를 바랍니다.

Javascript가 현재 SSL 연결을 확인할 수없는 경우 대안은 무엇입니까?

이것이 순수한 JavaScript 솔루션에서 가능하거나 불가능할 수 있기 때문에이 질문에 Flash로 태그를 지정하여이를 수행 할 수 있어야하며 응답을 Javascript로 다시 보냅니다.

누구든지 Java ME 경험이 있다면 가능하다면 언급하십시오. 널리 배포 된 다른 플러그인에서도 마찬가지입니다.

관련 기술에 대한 소스 코드를 높이 평가합니다.

14
goodguys_activate

대안에 대해 물었습니다. 솔직히 말해서 이것은 어려운 일입니다. 누군가 SSL 세션에서 중간자 (man-in-the-middle)를 재생 중이고 사용자가이를 인식하지 못하거나 진행하도록 허용 한 경우 실제로 어려운 위치에있게됩니다. 그러나 Javascript가 서버 가이 HTTPS 연결에서 제공 한 인증서를 확인할 수없는 경우 고려할 수있는 몇 가지 대안을 브레인 스토밍하려고합니다. 이 두 가지 아이디어 모두 완벽하지는 않지만, 도움이 될 수 있도록 전달하겠습니다.

아이디어 1. 브라우저를 신뢰하지 마십시오. 가능한 대안은 2 단계 인증 및 확인을 사용하여 브라우저 세션에 100 % 의존하지 않는 것입니다. 예를 들어, 온라인 뱅킹 응용 프로그램의 경우 사용자가 민감한 작업을 수행하면 서버는 사용자의 핸드폰에 거래 정보를 나열하는 SMS 메시지를 보낼 수 있습니다 ( "AT & T에 $ 100을 지불 하시겠습니까?" 이 PIN : 2781 ")을 입력 한 다음 사용자의 승인에 응답하거나 브라우저 세션에 PIN)를 입력해야합니다. 그러나 사용자에게는 불편하고 불편한 점이 있습니다.

아이디어 2. 원시 소켓 탐색 할 수있는 또 다른 가능성 : Flash 또는 Java를 사용하여 원시 소켓을 일부 TCP 포트 프록시에 의해 가로 채기/맨인 더미들에 속하지 않는 경우 프록시를 탐지 할 수있는 여러 가지 옵션이 있습니다. 단 하나의 간단한 탐지 전략 : 서버에서 서버와 연결된 소스 IP 주소가 원시 소켓이이 HTTPS 연결과 연관된 소스 IP 주소와 다릅니다 (그러나 이것이 잘못된 경보를 생성 할 수 있습니다 ...) 또한 플래시 또는 Java 브라우저가 인식하지만 프록시가 가로 채지 않는 다른 프로토콜 처리기 (예 : ftp : // 등).

5
D.W.

아니요-DOM은 현재 페이지의 SSL 인증서에 대한 액세스를 공개하지 않습니다. 액세스 권한은 location.protocol HTTPS를 통해 전달되고 있는지 확인할 수 있습니다.

4
blowdart

웹 브라우저 컨텍스트에는 두 가지 종류의 SSL 연결이 있습니다. 브라우저가 관리하는 것과 Java (Java, Javascript 등)가 자체적으로 관리하는 것입니다.

브라우저는 서버 인증서 체인에 대한 세부 정보를 제공하지 않기 때문에 첫 번째 종류의 경우 대부분 운이 좋지 않습니다. 브라우저는 "이것은 모두 멋지다"고 알려주지 만 브라우저가 타락하지 않았는지 확인할 수있는 방법은 없습니다.

두 번째로, 이것은 코드가 서버에 대한 연결을 열고 완전한 SSL 핸드 셰이크 자체를 실행한다는 것을 의미합니다. 이 시점에서 물론 코드는 서버에서 인증서 체인을 참조 인증하고 "직접 신뢰"(클라이언트 코드는 이미 "알고있다")를 포함하여 임의의 방식으로이를 검증 할 수 있습니다. 서버 공개 키) 또는 적어도 예상되는 특정 루트 CA를 사용합니다. 이 접근 방식에는 몇 가지 실질적인 문제가 있으며 비용이 많이 듭니다.

  • 완전한 SSL 구현을 포함해야합니다. 이것은 반드시 크지는 않지만 까다로울 수 있습니다. 클라이언트와 서버 코드를 모두 제어하기 때문에 더 작게 만들 수 있으므로 사용하려는 정확한 프로토콜 버전과 알고리즘에 집중할 수 있습니다.
  • JIT 컴파일러 없이 인터프리터를 사용하는 경우 성능이 문제가 될 수 있습니다.
  • 이 모든 것은 클라이언트 코드가 변경되지 않았 음을 확신 할 수있는 경우에만 의미가 있습니다. Javascript 코드 자체가 다운로드 된 SSL 연결에 대해 Javascript로 무엇이든 점검하는 것은 쓸모가 없습니다. Man-in-the-Middle Javascript 코드를 변경하여 검사를 제거 할 수 있습니다.
  • 클라이언트 코드에서 서버에 대한 원시 연결을 여는 것은 특히 proxy와 관련하여 일부 네트워크에서는 까다 롭습니다.

성능을 위해 Java ME 를 사용하려고합니다. 대부분의 Java ME 구현은 기본 인터프리터를 사용하므로 Javascript 또는 Flash보다 빠르지 않습니다. except ​​Java ME 표준 라이브러리에 Java.math.BigInteger가 포함되어 있습니다. 임의로 큰 정수에 대한 산술 연산은 일반적으로 네이티브 코드로 구현되므로 매우 빠릅니다. SSL 핸드 셰이크와 관련된 RSA 또는 DH 계산에이 기능이 필요합니다.

올바른 코드가 클라이언트에서 실행되고 있는지 확인하기 위해 Java ME 애플릿이 signed 일 수 있으므로 Java ME가 다시 구조에 올 수 있습니다. Fiddler를 실행할 수있는 공격자는 로컬 신뢰 저장소에 자신의 가짜 CA를 삽입 할 수있는 공격자이므로이 방법으로 문제를 해결할 수는 없습니다. 동일한 공격자가 자신의 가짜 CA를 다른 로컬 신뢰 저장소 (애플릿 서명 인증서의 유효성 검사)에 추가했을 수 있습니다. 그러나 이것은 멋진 트위스트를 추가합니다. if 클라이언트 연결이 차단 된 후 사후 법의학 검사에서 캐시 된 서명 된 애플릿을 발견 한 후 애플릿이 가짜이며 서버 관리자로서 당신은 나쁜 사람이 아닙니다. 인증으로부터 이러한 종류의 법적 보호를받을 수는 없지만 서명이 도움이 될 수 있습니다. 물론 이것은 상황에 따라 크게 달라집니다.

프록시 문제는 심각합니다. 많은 로컬 네트워크, 특히 회사는 NAT ; 대신 모든 외부 트래픽이 일부 프록시를 통과해야합니다. 사용자의 웹 브라우저는 프록시가 어디에 있는지 알고 있지만 Javascript 또는 Java 코드는 알고 있지 않습니다. 또한 프록시는 로컬 세션 자격 증명과 연결될 수있는 인증이 필요할 수 있습니다. 다시 브라우저는 코드가 아닌 투명하게 처리됩니다. 이러한 종류의 문제에 대처하기 위해 HTTP 요청을 통해 SSL 트래픽 터널링을 계획 할 수 있습니다.이 요청은 프레임 워크에서 제공하는 HTTP 코드로 전달됩니다. 이것은 가능하지만 (약 10 년 전에 했음) 쉽지는 않습니다.


그러나 이것은 모두 나쁜 냄새가납니다. 공격자가 X.509 트러스트 모델 (예 : 클라이언트 시스템에 자체 불량 CA를 신뢰할 수있는 CA로 설치합니다. OS 소프트웨어 업데이트 also는이 트러스트 모델을 사용하므로, 그 당시 클라이언트 시스템은 적어도 잠재적으로 공격자를 완전히 제어하고 있다고 가정해야합니다. 어떤 방식으로, 피들러는 악한 사람들이 사용하는 것이 아닙니다. 피들러가 작동하도록 허용하는 조건은 위에서 언급 한 악한 사람들이 훨씬 더 크고 철저한 규모의 악을 행할 수 있기 때문입니다.

Javascript 또는 Java ME 클라이언트 측 코드에서 SSL 연결에 대한 사항을 확인하는 것은 거실 테이블에 대한 멋진 메모만큼 쓸모가 없으며, 잠재적 인 도둑이 경찰에게 친절하게 전화를 걸도록 요청합니다.

(그러나 캐나다에서는 효과가있을 수 있습니다.)

4
Thomas Pornin

위협 모델 (SSL을 프록시하지만 검사 코드를 무단 변경하지 않는 프록시 감지)을 고려하면 콘텐츠를 체크섬하여 서버가 계산 한 하드 코드 된 체크섬과 비교하는 모든 페이지에 Javascript 코드를 포함시킬 수 있습니다. 클라이언트에 도달 한 페이지가 서버가 보낸 것과 일치하는지 확인합니다. 그러나 나는 여기에 사소한 기술적 과제가 있다고 생각하며, 그것이 당신을 많이 사게 될 것이라고 확신하지 않습니다 (악의적 프록시가 항상 검사 코드를 제거 할 수 있음을 명심하십시오).

스위스 에 대해 배우고 워싱턴 대학에서 "web tripwires" 에 대해 배우고 싶을 것입니다.

3
D.W.

이것은 현재 브라우저에서 지원하지 않습니다.

이를 지원하기 위해 Firefox의 뛰어난 버그 가 있지만 해결되지 않았습니다.

Emscripten으로 컴파일 된 OpenSSL 를 사용하여 Javascript에서이를 지원할 수 있습니다. 링크는 뼈만 제공하지만 앱에 대한 JS 링크를 작성해야합니다.

Adobe Alchemy (검색)로 컴파일 된 OpenSSL을 사용하여 Flash에서이를 지원할 수 있지만 최신 Flash 엔진 및 OpenSSL에 대한 작업을 다시 실행해야합니다.

1
Joe Steele

Silverlight & .NET까지는 일반적으로 ServicePointManager를 사용하여 SSL 인증서의 유효성을 검사하기 위해 호출을 차단하지만 SL4에서는 불가능한 것으로 보입니다.

Microsoft Connect 에 대한 게시물이 있지만 Microsoft는 의도적으로 설계된 것이라고 말합니다. 이 기능을 Silverlight 개발자가 사용할 수 있어야한다고 생각하는 사람은 누구나 답변을 게시 할 것을 권장합니다.

0
goodguys_activate