php7 - Número de puerto incorrecto devuelto por $_SERVER

php7 0 openssl

Question

Escenario: Estoy trabajando en un servidor web Apache con algo de PHP. Apunto mi navegador a https://my.example.com/test.php que tiene las siguientes líneas de código:

<pre>
<?php
print_r($_SERVER);
?>
</pre>

El valor impreso para SERVER_PORT es 80 , no 443 . Pero si voy a https://my.example.com:80/test.php el servidor web (Apache) barfs (Ocurrió un error durante una conexión a my.example.com:80. SSL recibió un registro que excedía el longitud máxima permitida. Código de error: ssl_error_rx_record_too_long). Si voy a https://my.example.com/test.php , la URL redirige a https://my.example.com/test.php sin errores ni problemas, excepto que mi PHP imprime que el puerto del servidor es 80 en lugar de 443.

Aquí está la sección relevante del archivo conf.d / ssl.conf ( eliminé lo que creo que son directivas extrañas y reemplacé la dirección IP real con la palabra IP_ADDRESS):

Listen IP_ADDRESS:443    
<VirtualHost *:443>
        ServerName my.example.com
        ServerAlias my
        DocumentRoot "/path/to/document_root/htdocs"
        Options +Indexes
</VirtualHost>

Aquí está la impresión completa de la variable $ _SERVER (con los detalles de mi servidor eliminados / modificados por ejemplos anónimos):

Array
(
    [HTTP_HOST] => my.example.com
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
    [HTTP_ACCEPT_ENCODING] => gzip,deflate
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [HTTP_KEEP_ALIVE] => 115
    [HTTP_CONNECTION] => keep-alive
    [HTTP_COOKIE] => PHPSESSID=randomstring_yes_I''m_that_paranoid
    [PATH] => /sbin:/usr/sbin:/bin:/usr/bin
    [SERVER_SIGNATURE] => 
Apache/2.2.3 (Red Hat) Server at my.example.com Port 80


    [SERVER_SOFTWARE] => Apache/2.2.3 (Red Hat)
    [SERVER_NAME] => my.example.com
    [SERVER_ADDR] => IP_ADDRESS_1
    [SERVER_PORT] => 80
    [REMOTE_ADDR] => IP_ADDRESS_2
    [DOCUMENT_ROOT] => /path/to/document_root/htdocs
    [SERVER_ADMIN] => [email protected]
    [SCRIPT_FILENAME] => /path/to/document_root/htdocs/test.php
    [REMOTE_PORT] => 49178
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => 
    [REQUEST_URI] => /test.php
    [SCRIPT_NAME] => /test.php
    [PHP_SELF] => /test.php
    [REQUEST_TIME] => 1292273758
)

Como puede ver, el SERVER_PORT es 80 y $ _SERVER [''HTTPS''] no está configurado. De acuerdo con los documentos de PHP, pensé que se debía establecer en un valor no vacío si se accede al script PHP a través de HTTPS (que es lo que estoy haciendo).

¿Tienes idea de lo que está pasando? Solo soy el desarrollador web. No administro este servidor, pero el administrador de mi servidor me dice que todo funciona, pero me gustaría saber por qué $ _SERVER [''SERVER_PORT''] está devolviendo 80 en lugar de 443 cuando veo una URL de HTTPS.

EDITAR: He editado el ejemplo anterior para ilustrar mis resultados en la impresión de la variable $ _SERVER completa.

EDITAR 2: Intentar https://my.example.com/test.php como se sugiere en los comentarios a continuación hace lo mismo: SERVER_PORT es 80 y HTTPS no está configurado (específicamente al intentar esta URL se redirige a https://my.example.com/test.php ).

EDIT 3: OK, he publicado lo que creo que es la respuesta a esto a continuación (TL; DR: mover las directivas SSL dentro de la directiva VirtualHost y cambiar esa directiva para que haga referencia a mi sitio usando su dirección IP en lugar de que aparezca un comodín resuelto el problema).

Answer 1

Hace poco encontré el mismo problema porque un código que tenía que estaba enmascarando el mismo problema se había interpuesto.

Mi diagnóstico del problema es el siguiente: Esta es una peculiaridad de un cambio realizado en Apache 2.0. La directiva Port ya no forma parte de las directivas httpd.conf, básicamente se divide entre las directivas ServerName y Listen.

Así que mi apache httpd.conf (Apache 2.2.23) tenía estas entradas

ServerName myservername.com
Listen: 5150

Sin embargo, PHP $ _SERVER [''SERVER_PORT''] devolvió 80 a todas las solicitudes realizadas en el puerto 5150.

Así que estudiando detenidamente los documentos de Apache, encontré una pequeña noticia acerca de que Port es una directiva desaprobada y ServerName la subsume.

Establecí mi directiva de servidor de la siguiente manera

ServerName myservername.com:5150
UseCanonicalName On
Listen 5150

y de repente, el script php estaba haciendo lo correcto, informando a _SERVER [''SERVER_PORT''] como 5150.

Alternativamente tu httpd.conf podría leer

ServerName myservername.com
UseCanonicalName Off
Listen 5150

Entonces, busqué en el código fuente de php (5.3.20) y el código fuente de apache hasta que encontré la fuente del comportamiento.

El comportamiento se basa en (al menos para el código fuente de 2.2.23 adjunto) en dirOfApacheSource/server/core.c Mire la función AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)

Aquí verá que si su directiva httpd UseCanonicalName está establecida en "On", el puerto se analiza fuera de la directiva ServerName. Cuando la directiva ServerName no tiene el formato ServerName myserver.com:myport número, el código del caso buscará un ap_default_port del objeto de solicitud (que la gente apache establece de manera predeterminada en 80).

Si le molesta que necesite agregar el puerto explícitamente a la directiva ServerName en httpd.conf, su otra opción es configurar UseCanonicalName en "Off", esto obliga al código en server / core.c a analizar la solicitud de URI para extraer el nombre del servidor y el puerto.

Seis de una, media docena de la otra, modifican su archivo httpd.conf de apache y pronto verán los resultados esperados.

Answer 2

Me parece recordar que esto me sucedió cuando actualicé mi apache hace un par de años. Terminó siendo un mal SSLCipherSuite, IIRC. Básicamente asegúrese de tener una configuración SSL completa:

¿Tienes tus claves, certificado y clave definidos? Y SSLEngine en? Algo así es requerido en tu configuración como mínimo ...

SSLEngine en

SSLCipherSuite ALL:! ADH:! EXPORT56: RC4 + RSA: + HIGH: + MEDIUM: + LOW: + SSLv2: + EXP: + eNULL SSLCertificateFile /path/to/apache/conf/server.crt SSLCertificateKeyFile / path / to / apache /conf/server.key

... y si desea verificar los certificados de cliente, también necesita algo como:

SSLVerifyClient requiere SSLVerifyDepth 10 SSLCACertificateFile /path/to/apache/conf/trustedpubkeys.crt

¡Buena suerte!

Si desea verificar que esto realmente está sucediendo, active un detector como tcpdump o wireshark. Para tcpdump usaría una línea de comandos como ...

tcpdump -i eth0 -nn -s 1600 ip proto 17 y host IP_ADDRESS

(donde IP_ADDRESS es el fqdn o quad punteado de su servidor)

Luego, obtenga su página de volcado var $ _SERVER, o una página phpinfo (), etc.

Su $ _SERVER var dump muestra su puerto remoto, por lo que debería poder ver cuál de sus conexiones usó ese puerto, y si estaba conectado al puerto 80 o 443.

Wireshark te dejaría hacer lo mismo, si eres más una persona de GUI.

Answer 3

OK, creo que lo descubrí. El administrador de mi servidor cambió el archivo conf.d / ssl.conf de

SSLEngine On
# and other SSL directives

<VirtualHost *:443>
        ServerName my.example.com
        ServerAlias my

        # and more directives
</VirtualHost>

a

<VirtualHost IP_ADDRESS:443>
        ServerName my.example.com
        ServerAlias my

        SSLEngine On
        # and other SSL directives

        # and more directives
</VirtualHost>

y ahora PHP está viendo el SERVER_PORT # (443) correcto y ahora también está configurado $ _SERVER [''HTTPS'']. Así que, o bien estaba colocando las directivas SSL dentro de la directiva VirtualHost para my.example.com o quizás estaba cambiando la directiva VirtualHost para hacer referencia a una dirección IP real en lugar de a un comodín que resolvió este problema. Gracias a todos por su ayuda en esto.