Apache : 안전하지 않은 요청이 보안 포트로 전송되었습니다…

머리말

첫째 : 단순히 포트 80-> 포트 443 다시 쓰기로 해결 되지 않습니다 . 거의 모든 이전 질문, 메일 스레드, 포럼 스레드 등에서 이것이 첫 번째 무지한 응답이며 여러 번 앵무새되었음을 발견했습니다.

둘째 : 예, 같은 포트에서 HTTP 및 HTTPS 트래픽을 제공 할 수 없습니다. 그렇지 않습니다.

대본:

포트 곱셈을 통해 여러 사이트를 호스팅하는 Apache 서버. 포트 80은 공개 사이트를 제공합니다. 포트 443은 해당 사이트의 보안 버전을 제공합니다.

포트 7443, 8443 및 9443은 각각 별도의 SSL 보안 사이트를 제공합니다.

사용자가 URL을 잘못 입력하거나 유효하지 않은 링크 (예 : http : //hostname.tld : 7443 )가 제공되면 다음과 같은 우스운 페이지가 표시됩니다.

Apache Bad Request 오류 메시지

서버 대신 https : //hostname.tld : 7443으로 리디렉션합니다 .

제 질문은 Zeus의 똥구멍 이름으로 어떻게 Apache의 동작이 나이 오류 메시지를 수정하여 사용자를 자동으로 리디렉션 할 수 있습니까?

아파치는 HTTPS에 대해 구성되었지만 HTTP가 아닌 요청 (오류 메시지를 표시하기 위해)을 제공하고 있습니다. 기본적으로 리디렉션을 수행하는 것만으로도 엄청나게 바보처럼 보이지만 동의하지 않더라도 왜 그들이 행동을했는지 이해할 수 있습니다. 내 질문은 : 당신이 그것을 바꿀 수 있습니까? 그들은 어딘가에서 오류를 처리하고 있으며 Apache가 구성 풍요의 뿔이기 때문에이 동작을 처리 할 수있는 지시어가 있다고 생각하지만 지금까지 몇 시간 동안 그것을 찾을 수 없었습니다.

최신 정보:

나는 다음을 포함하여 다양한 것들을 시도했다.

사용 ErrorDocument 400지시하는 것은 CGI 그냥 보내 PHP 스크립트에 도착합니다 Status 301및 Location헤더. 빈 페이지가 나타납니다. ErrorDocument 400 https://hostname.tld:7443단순히 사용 하면 해당 링크가 페이지에 표시됩니다.
mod_rewrite사이트 전체를 지시하는 총괄 진술을 포함하여 I 또는 Google 의 거의 모든 조합을 사용할 수 있습니다. 이것들 은 작동 하지 않습니다 . 말 그대로 그들은 아무것도하지 않습니다. 아파치가 다시 쓰기 지시문을 처리하기 전에 위의 오류를 겪고 있다고 생각합니다.

사용자 지정 포트 사용으로 인해 포트 기반 리디렉션을 사용할 수 없습니다. http / https 불일치로 인해 스크립트 기반 리디렉션이 제공되지 않으므로 스크립트 기반 리디렉션을 사용할 수 없습니다. 나는 이것을 거의 버그 나 의도하지 않은 행동으로 초안하려고하지만, 누군가가 매우 맞춤형 오류 메시지를 넣을 것을 미리 알고 있었기 때문에 그들은 당신이 아마도 그들이 이미 제공하고있는 URL ?

— 필맨
소스

참고 항목 허용 대답 에 대한 SSL 및 단일 포트에 비 SSL 모두

— 다니엘 베리 테

Daniel, 그것은 내가 찾은 많은 질문 중 하나이며이 질문을 게시하기 전에 시도한 해결책입니다. 문제는 PHP 구성 요소라고 생각하지만 @hrunting의 답변 업데이트가 나에게 아름답게 작동하기 때문에 이미 가지고있는 것보다 더 이상 시간을 낭비하지 않을 것입니다. 적어도 내가해야 할 때까지.

— peelman

링크 된 비디오에 대한

— 찬성

답변:

필자는 이것이 Apache 2.2 이하 가이 특정 상황을 처리하는 방식의 버그라고 생각합니다.

SSL 읽기 400 Bad Request오류에서 Apache 2.2는 HTTP 응답 코드 또는 헤더를 반환하지 않고 HTTP 응답 본문 만 반환합니다. telnetting하여 포트 443에 테스트하고 다음을 전송합니다.

GET / HTTP/1.1

서버는 즉시 (나를 위해) 반환합니다.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://server.tld/"><b>https://server.tld/</b></a></blockquote></p>
</body></html>

HTTP 응답 코드 또는 HTTP 헤더가 없음에 유의하십시오.

Apache 2.4 서버 에서이 작업을 수행하면 다음과 같은 결과가 나타납니다.

HTTP/1.1 400 Bad Request
Date: Sun, 10 Feb 2013 00:47:23 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0g
Content-Length: 462
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<hr>
<address>Apache/2.4.3 (Unix) OpenSSL/1.0.0g Server at server.tld Port 443</address>
</body></html>

내가 한 것처럼 ErrorDocument 줄을 설정하면 :

ErrorDocument 400 https://server.tld/

그런 다음 302 리디렉션에 대한 HTML을 얻지 만 헤더는 없습니다. 302 리디렉션 응답 코드와 Location:헤더가 없으면 브라우저가 리디렉션되지 않습니다.

Apache 2.4로 업그레이드하여 작동하는지 확인하십시오. 필자는 Apache 2.4.3 이상을 테스트하고 확인했지만 이것이 언제 업데이트되었는지 정확하게 파악하려는 노력을 기울이지 않았습니다. 나는 많은 양의 작업에서 2.4를 준비하면서 바람직하지 않은 행동을 부작용으로 수정했다고 생각합니다.

관련 Apache httpd 버그 :

44907
50823

최신 정보

버그가있는 Apache가 스크립트에 헤더를 인쇄하여 (클라이언트에 전송되지 않음) 원하는 동작 (리디렉션)을 제공하도록 한 다음 원하는 헤더를 수동으로 다시 인쇄 할 수 있습니다. Apache 2.2.22에서 작동하는 기본 Perl 스크립트는 다음과 같습니다.

#!/usr/bin/perl

use strict;
use CGI;

my $q = CGI->new();

# this will cause Apache to handle the response properly, but is meaningless otherwise
print $q->redirect("https://localhost/");

# this actually performs the redirect
print "HTTP/1.1 302 Found\r\n";
print "Location: https://localhost/\r\n";
print "\r\n";

# you can do whatever you want here; this will be the HTML body

SSL없이 SSL 포트와 통신하는 것 외에 400이 생성 될 수있는 다른 이유가 있음을 알고 있어야합니다. 이를 판별하는 쉬운 방법은 HTTPS환경 변수 를 찾는 것입니다 . 설정되면 SSL이 올바르게 협상되고 다른 원인으로 인해 400이 발생합니다 (이 경우 이중 헤더 트릭을 수행하지 마십시오). 경우 HTTPS설정되지 않은, 위로 리디렉션을 반환합니다.

— 자르기
소스

거룩한. 쓰레기. 완벽한 답변. 그라시아 스.

— peelman

필자는이 글을 읽을 때 "아파치 2.2가 있고 이런 종류의 리다이렉션 동작을 원한다면 정말 짜증 난다"고 생각한다. 우분투 시스템에 적합한 Apache 2.4 deb를 찾거나 노력하지는 않을 것입니다. PHP 스크립트에서 솔루션을 해킹 할 수 있습니다. Apache는 분명히 출력을 클라이언트에 덤프하므로 특정 예상 콘텐츠를 반환하면 Apache를 업그레이드하지 않고도 원하는 동작을 얻을 수 있습니다. PHP 스크립트가 "HTTP / 1.1 302 Found \ r \ nLocation : server.tld \ r \ n \ r \ n"을 출력하도록하십시오.

— 4

문제는 PHP 스크립트가 처리되고 있지 않다는 것입니다. 이것은 현재 Ubuntu Server 12.04의 Apache 2.2.22에 있습니다. 그리고 네, 정말 정말 짜증납니다. 특히 버그 보고서에서 리디렉션을 자동으로 수행하는 옵션을 제공하지 않아도 완전히 설정 된 것처럼 보이며 2.2가 수정 될 것이라는 희망은 거의 없습니다.

— peelman

그리고 위에서 말했듯이 보안으로 리디렉션하는 대신 오류 메시지를 작성하는 데 어려움을 겪는 이유가 이해가되지 않습니다 (심각하게도 리디렉션하지 않는 이유는 무엇입니까?) 나는 그것이 나쁜 생각이라고 생각합니다).

— peelman

나는 피의 메시지의 텍스트를 찾고 전체 파일 시스템을 파악하여 그들이 어디에서 그것을 거칠 수 있는지 볼 수 있었는지, 오프 기회에 <javascript태그를 삽입하고 해킹 리디렉션으로 운이 좋을 수도 있지만, 지금까지는 그렇지 않았다. 주사위. 이것에 대해 아무것도 엄밀한 아파치 awesomeness를 따르는 방식으로 처리되지 않는 것 같습니다 ...

— peelman

-1

mod-rewrite로이 문제를 해결할 수 있습니다. 일치하는 규칙을 설정하십시오. Stackoverflow 에서이 답변을 참조하십시오

— 트렌트
소스

아니요, 이미 시도했지만 작동하지 않습니다. http / https가 먼저 일치하지 않기 때문에 ModRewrite 단계에 도달하지 않는 것처럼 보입니다.

— peelman

HRM 난 당신의 최고 아파치 설정 파일에서 시작하고 호출 상황을 확인하기 위해 아래에 당신의 방법을 일한 가정 있도록

— 트렌트

실제로 전체 sites-available디렉토리를 기억했습니다 . 넌센스로 리디렉션하거나 다른 사이트, 다른 포트 등으로 리디렉션하더라도 400 잘못된 요청을 계속로드합니다.

— peelman