https를 다른 https로 리디렉션


28

나는이 질문에 대해 인터넷 검색을 해왔으며 아이러니하게도 구체적인 답변을 찾을 수 없습니다. 나는 과거 에이 질문에 스스로 대답했지만 지금은 내 자신의 설명을 기억할 수 없습니다.

일 년에 여러 번 누군가가 저에게 이것을하도록 요청할 것입니다. 나는 이것을 설명하는 일종의 존경할만한 기사를 지적하고 싶습니다.

https://www.example.com/ 에서 URL을 가져 와서 트래픽을 https://www.example2.com/으로 리디렉션하고 싶습니다 .

나는 이것이 기술적으로 가능해야한다고 생각하지만 바람직하지 않습니다. 이 방법에 어떤 문제가 있습니까? 브라우저를 다른 사이트로 리디렉션 한 후 브라우저에 보안 팝업이 표시됩니까? 누구든지 이것을 설명하는 훌륭한 문서에 대한 링크를 제공 할 수 있습니까?


4
당신의 상황은 성가 시지만, 아이러니하지는 않습니다.)
Gareth

답변:


17

두 사이트 모두 유효한 SSL 인증서가 있어야합니다. 이런 식으로 브라우저는 보안 팝업을 제공하지 않습니다. 그러나 두 사이트가 모두 동일한 서버에 있으면 두 도메인 모두 다른 IP 주소에서 호스팅해야합니다.

웹 서버는 HTTP 요청에서 "Host"헤더를보고 어떤 사이트를 제공해야하는지 확인합니다. SSL 협상은 HTTP 요청이 전송되기 전에 발생하므로 웹 서버는 어떤 웹 사이트를 표시할지 알 수 없습니다. 항상 동일한 인증서를 브라우저에 보냅니다.

이 문제를 해결하는 두 가지 방법이 있습니다.

  • * .example.com에 대한 와일드 카드 인증서가 있으므로 모든 하위 도메인이 동일한 인증서를 공유 할 수 있습니다.
  • 각 SSL 사이트를 다른 IP 주소에서 실행하십시오. 이런 방식으로 웹 서버는 들어오는 연결을받은 IP 주소를 검사하여 브라우저에 보낼 수있는 SSL 인증서를 알고 있습니다.

여러 개의 IP 주소를 동일한 네트워크 어댑터에 완벽하게 연결할 수 있습니다. IP 주소 공간에서 사용 가능한 두 번째 IP 주소 만 있으면됩니다.

업데이트 : 요즘에는 단일 IP에서 여러 SSL 사이트를 실행할 수 있습니다. 이를 가능하게하려면 웹 서버에서 SNI 지원을 구성하십시오. 대부분의 최신 브라우저 (Windows XP 및 Android 2 제외)가이를 지원합니다.


1
UCC (Unified Communication Certificate)에 따라 동일한 IP에서 여러 SSL 사이트를 호스팅 할 수도 있습니다. help.godaddy.com/article/3908
ManiacZX

다중 호스트 이름 / 하나의 IP 인증서 문제에 대한 다른 해결 방법은 대체 포트 번호를 사용하는 것입니다. 일부 방화벽 / 공용 액세스 포인트는 80/443이 아닌 트래픽을 차단하므로 이상적이지 않습니다.
Bryan Agee

5

나는 이것을 시도하지 않았으므로 구체적인 경험으로는 말하지 않지만 작동해야합니다. 호스트 이름이 HTTP 헤더 내에서 암호화되므로 서버가 암호 해독 될 때까지 경로를 재지 정하지 못하므로 https://www.example.com에 유효한 SSL 인증서가 있어야합니다 . 그 후 정상적인 HTTP 요청처럼 리디렉션해야합니다.


2

이것이 바람직하지 않은 이유는 무엇입니까?

예를 들어, Big Bank와 Little Bank는 모두 고객에게 행복하고 안전한 느낌을주기 위해 https 사이트를 운영합니다. Big Bank는 Little Bank를 인수합니다. 어떤 시점에서 IT 사람들에 대한 리디렉션 설정합니다 https://www.littlebank.comhttps://www.bigbank.com을 . 이것이 https에서 https로 리디렉션되는 합법적 인 이유입니다.

이것은 잘 작동합니다.


브라우저가 여전히 www.littlebank.com을 표시하도록 실제 주소가 마스크 된 상태에서 www.littlebank.com으로 이동하여 www.bigbank.com으로 리디렉션 된 경우 설명 된 시나리오는 문제가되지 않습니다. 의회. 이는 관련성이없는 비보안 사이트에서는 상당히 흔하지 만 실제로 자신이 아닌 안전한 웹 사이트로 표시되는 데 따르는 고유 한 위험을 볼 수 있습니다.
찰스

1

내가 생각할 수있는 현재 응답에 존재한다고 생각되는 단절은 이러한 상황 중 하나에서 진정한 리디렉션 (예 : 브라우저가 www.example2.com으로 다시 지정됨)은 좋지만 이것을 가리면 브라우저가 실제로 당신이 www.example2.com에 전송 한 때 www.example.com에서 뾰족 stillthinks 있도록, 이것은 당신이 사용자를 스푸핑하는 것을 시도 할 수 정확하게 때문에 보안 경고를 볼 수있는 곳입니다.

짧은 버전은 정상적인 경로 재 지정이 좋으며 주소 마스킹은 아마도 많은 설명을 남길 것입니다.


고마워 찰스 그것은 내가 생각했던 "불시의"상황이어야합니다.
Stefan Lasiewski

0

알다시피,이 문제는 전송 계층에서 해결 될 수 있습니다. example.com에 192.168.0.1을 가리키는 DNS A 레코드가 있다고 가정 해 봅시다. 브라우저에 https://example.com 을 입력하면 PC가 IP 192.168.0.1로 서버에 TCP 연결을 설정했으며 일부 프로세스는 포트 443에서 수신 대기합니다. 서버가 동시에 시도하지 않는 경우 SSL 협상 시작과 같이이 TCP 세션을 통해 전송 된 데이터에 대한 세부 정보를 얻음) 192.168.0.2에 대한 TCP 연결을 설정합니다 (DNS가 example2.com 인 DNS가있는 다른 서버). 그런 구성 :

defaults
        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443 192.168.0.1:443
    server back443 192.168.0.2:443

그러나 example2.com 웹 서버가 CN = example2.com 및 SAN = example.com과 같은 SSL 인증서를 표시하지 않으면 SSL 인증서 오류가 발생합니다.

또는 사용자 perstective example.com 및 example2.com에서 192.168.0.1로 분석 할 때 DNS slpit horizon을 설정할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.