☰

ScriptAlias ​​hace que las solicitudes coincidan con demasiados bloques de ubicación. ¿Qué está pasando?

tag-icon • tag-icon apache-2.2 ssl web-server configuration
ScriptAlias ​​hace que las solicitudes coincidan con demasiados bloques de ubicación. ¿Qué está pasando?

Deseamos restringir el acceso a nuestro servidor de desarrollo a aquellos usuarios que tengan un certificado de Cliente SSL válido. Estamos ejecutando Apache 2.2.16 en Debian 6.

Sin embargo, para algunas secciones (principalmente git-http, configuración con gitolite enhttps://mi.servidor/git/) necesitamos una excepción ya que muchos clientes git no admiten certificados de cliente SSL.

Logré requerir autenticación de certificado de cliente para el servidor y agregar excepciones para algunas ubicaciones. Sin embargo, parece que esto no funciona para git.

La configuración actual es la siguiente:

SSLCACertificateFile ssl-certs/client-ca-certs.crt
<Location />
  SSLVerifyClient require
  SSLVerifyDepth 2
</Location>
# this works
<Location /foo>
  SSLVerifyClient none
</Location>
# this does not
<Location /git>
  SSLVerifyClient none
</Location>

También probé una solución alternativa, con los mismos resultados:

# require authentication everywhere except /git and /foo
<LocationMatch "^/(?!git|foo)">
  SSLVerifyClient require
  SSLVerifyDepth 2
</LocationMatch>

En ambos casos, un usuario sin certificado de cliente puede acceder perfectamente a my.server/foo/, pero no a my.server/git/ (el acceso se rechaza porque no se proporciona ningún certificado de cliente válido). Si desactivo completamente la autenticación del certificado de cliente SSL, my.server/git/ funciona bien.

El problema de ScriptAlias

Gitolite se configura utilizando la directiva ScriptAlias. Descubrí que el problema ocurre con cualquier ScriptAlias ​​similar:

# Gitolite
ScriptAlias /git/ /path/to/gitolite-shell/
ScriptAlias /gitmob/ /path/to/gitolite-shell/
# My test
ScriptAlias /test/ /path/to/test/script/

Tenga en cuenta que /ruta/a/prueba/script es un archivo, no un directorio, lo mismo ocurre con /ruta/a/gitolite-shell/

Mi script de prueba simplemente imprime el entorno, súper simple:

#!/usr/bin/perl

print "Content-type:text/plain\n\n";
print "TEST\n";
@keys = sort(keys %ENV);
foreach (@keys) {
    print "$_ => $ENV{$_}\n";
}

Parece que si voy ahttps://my.server/test/someLocation, que se están aplicando todas las directivas SSLVerifyClient que se encuentran en bloques de ubicación que coinciden con /test/someLocationo simplemente / alguna ubicación.

Si tengo la siguiente configuración:

<LocationMatch "^/f">
        SSLVerifyClient require
        SSLVerifyDepth 2
</LocationMatch>

Entonces, la siguiente URL requiere un certificado de cliente:https://my.server/test/foo. Sin embargo, la siguiente URL no:https://my.server/test/somethingElse/foo

Tenga en cuenta que esto sólo parece aplicarse a la configuración SSL. Lo siguiente no tiene ningún efecto sobrehttps://my.server/test/foo:

<LocationMatch "^/f">
        Order allow,deny
        Deny from all
</LocationMatch>

Sin embargo, bloquea el acceso ahttps://mi.servidor/foo.

Esto presenta un problema importante en los casos en los que tengo algún proyecto ejecutándose enhttps://mi.servidor/proyecto(que debe requerir autorización de certificado de cliente SSL),yhay un repositorio git para ese proyecto enhttps://my.server/git/projectque no puede requerir un certificado de cliente SSL. Dado que la URL /git/project también coincide con Locationlos bloques /project, dicha configuración parece imposible dados mis hallazgos actuales.

Pregunta: ¿Por qué sucede esto y cómo soluciono mi problema?

Al final, quiero solicitar la autorización del certificado de Cliente SSL para todo el servidor excepto /git y /someLocation, con la configuración más mínima posible (para no tener que modificar la configuración cada vez que se implementa algo nuevo o una nueva se agrega el repositorio git).

ActualizarMás información: Tenga en cuenta que en algunos casos,https://mi.servidor/proyectoen realidad es un proxy inverso, por lo que una <Directory /path/to/project>directiva es imposible. Si quiero proteger esa aplicación con un certificado de cliente SSL, esto debe ser necesariamente con un bloque <Location /project>(o más general ).<Location />

Actualización 2Acabo de probar esto en Apache 2.4.3, con el mismo resultado. Si esto se debe a algún error, al menos está presente en dos versiones.

Nota: reescribí mi pregunta (en lugar de simplemente agregar más actualizaciones en la parte inferior) para tener en cuenta mis nuevos hallazgos y, con suerte, aclarar esto.

Respuesta1

Según la corrientedocumentación de apacheesto podria ser un problema:

En el contexto por servidor, se aplica al proceso de autenticación del cliente utilizado en el protocolo de enlace SSL estándar cuando se establece una conexión. En el contexto por directorio, fuerza una renegociación SSL con el nivel de verificación del cliente reconfigurado después de que se leyó la solicitud HTTP pero antes de que se envíe la respuesta HTTP.

¿Qué tal si utilizamos el contexto <Directorio> en lugar de <Ubicación>? Una entrada para el nivel raíz y la otra para la ruta Script-Alias: /path/to/gitolite-shell/

Actualizar:

Encontré algunos consejos para este caso ->Pregunta/Respuesta en Stackoverflow

información relacionada