SSL 또는 일반 http에 바인딩 될 수있는 웹 서비스가 있습니다. 서버 호스트 및 포트를 알 수 있도록 구성된 Java 클라이언트. 클라이언트가 연결되면 http://host:port/service과 같은 서버 끝점을 구성합니다. 클라이언트는 서버가 SSL을 사용하는지 여부를 알지 못합니다. 서버는 항상 단일 포트에 바인드되어 안전하거나 안전하지 않습니다. 자, 문제는 클라이언트가 다른 매개 변수를 도입하지 않고 이것을 발견하는 방법입니다. 일반 HTTP 요청에 도전 한 다음 특정 예외가 발생하면 SSL (또는 부사)로 다시 폴백 할 수 있습니까? 아니면 클라이언트에 대한 새로운 연결 매개 변수를 명시 적으로 도입해야합니까?SSL을 정상적으로 감지하는 방법
서버 측에서는 Grizzly's port unification 구현과 같은 메커니즘을 사용할 수 있습니다. 동일한 포트에서 HTTP 및 HTTPS를 제공하는 데 사용할 수 있습니다. 이는 두 경우 모두 클라이언트가 먼저 대화하고 HTTP 요청 또는 SSL/TLS 클라이언트 Hello 메시지를 전송한다는 사실에 의존합니다. 이것은 서버 측에서 매우 편리합니다 (일반적으로 동일한 포트에서 두 개의 프로토콜을 실행하는 것이 좋을지는 모르겠지만). (당신이 무슨 요구하는지 무엇을) 클라이언트의 관점에서
의 결과는 다음과 같습니다
포트 통합을 제외하고 (이것은 드문 경우입니다.) 이전 시도의 결과를 캐시하려고 할 수 있습니다.
더 근본적으로, 보안 관점, 사용되어야하는 프로토콜 모르고에서 취약점을 소개 : 시스템 (blindly relying on automatic redirects이처럼 비슷한 방법으로) 공격을를 다운 그레이드 공개됩니다. 사용자 에이전트가 HSTS을 지원한다면, 사용자 에이전트가 HTTPS와 함께 사용되는 사이트를 기억하도록 요구할지라도 조사 할 가치가 있습니다.
어느 쪽이든 보안이 염려되는 경우 은이어야 클라이언트가 https://을 사용해야하는시기를 알 수 있도록 구성해야합니다.
이것은 내가 겪은 것처럼 보입니다. 보안이 중요합니다. 그렇지 않으면 SSL이 처음부터 없었을 것입니다. 그러나이 특별한 경우에는 트래픽을 암호화하기 만하면되므로 인증이 문제가되지 않기 때문에 큰 문제는 아닙니다. 사실,이 경우 클라이언트는 실제로 동일한 종류의 다른 노드를 호출하는 서버 노드입니다 (클러스터 내에서 어떤 종류의 대화입니다). 새 매개 변수를 사용하지 않으려면 멋진 단축키가 필요했습니다. 믿을만한 방법이없는 것처럼 들리지만, 포트 통일로 재미있게 놀아 보겠습니다. – Dima
트래픽을 전혀 변경할 수없는 수동 공격자 (엿듣기)가 있음을 확실히 알지 못하는 경우 암호화를 사용하기 전에 서버 인증이 항상 문제가됩니다. – Bruno
예, 그렇습니다. 도청자는 내 경우에 위협이되지 않습니다. – Dima