[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]On Sat, 16 Nov 2002, Sandino Araico Sánchez wrote: > > No es asi, no tiene nada que ver con los certificados ni con los virtual > > hosts que declaras en la configuracion del apache. > > No estoy de acuerdo. > Tiene que ver con la configuración del Apache cuando declaras el host virtual que van > con ssl habilitado porque ahí le dices dónde se encuentra la llave que va a cargar al > arancar y dónde se encuentra el certificado que va a mandar durante la negociación de > ssl cuando llegue a ese host virtual. Ese es precisamente el problema. Cuando se usa el Apache con SSL, estas corriendo el protocolo HTTP sobre el protocolo SSL. Primero se tiene que hacer el handshake del SSL entre el cliente y el servidor y solo hasta que se establece la conexion segura entre ambos, es que empieza a transmitirse la informacion del protocolo HTTP, no antes. Hay dos posibles maneras de declarar un virtual host en el apache. Por IP, donde no hay problema con el SSL, porque el apache-ssl esta "escuchando" en esa direccion y puerto y tiene toda la informacion necesaria para hacer el intercambio de llaves. El otro es por nombre, que no funciona con SSL, porque es en el encabezado de la peticion del HTTP donde viene el nombre del host virtual y esta informacion no la tiene, no la puede tener el SSL para hacer el handshake, porque no sabe aun nada sobre el nombre del host virtual que viene en el encabezado del HTTP. No puede enviarse esta peticion con el nombre antes de que la conexion SSL este establecida. > Todos los handshakes de todos los protocolos que usan TCP/IP requieren la IP dle > servidor ¿no? Asi es, y nuevamente ese es el problema, con virtual host por nombre tu no tienes la IP de este, tienes la IP de servidor "primario" y eso no te sirve para que el SSL trabaje con el virtual host. > Cuando arranca el APACHE revisa que no haya dos hosts virtuales habilitados con SSL (o > uno con SSL y el otro sin SSL) escuchando al mismo tiempo en la misma dirección IP y > en el mismo puerto. Si se encuentra una combinación así se niega a arrancar. Una vez > que arranca carga en memoria todas las llaves privadas de todos los hosts virtuales > habilitados con SSL, te pide las contraseñas de las llaves que se encuentra > encriptadas. Pero en el caso de virtual host por nombre, solo podria usarla cuando ya se establecio la conexion segura y eso no puede darse porque no sabe como "se llama" el virtual host > Pero no dice que no se pueda usar SSL en hosts virtuales basados en IP o hosts > virtuales basados en puerto. Asi es, pero hasta donde recuerdo la pegunta, el problema era con hosts virtuales por nombre. Si tienes muchas IPs, pues ya la hiciste. > Y aunque te excluya de usar hosts virtuales basados en nombre no te prohibe usar > varios ServerAlias en la definición del host virtual y manejar la virtualización de > hosts dentro de tu motor de aplicaciones. IDEM, Si no tienes los IPs, pues tienes que darle la vuelta usando otros puertos > > The reason is very technical. Actually it's some sort of a chicken and egg > > problem: The SSL protocol layer stays below the HTTP protocol layer and > > encapsulates HTTP. When an SSL connection (HTTPS) is established > > Apache/mod_ssl has to negotiate the SSL protocol parameters with the > > client. For this mod_ssl has to consult the configuration of the virtual > > server (for instance it has to look for the cipher suite, the server > > certificate, etc.). > > En este momento es donde tu cliente verifica el commonName (CN) del certifiacdo que te > manda el servidor contra el nombre del host que estás pidiendo en la URL. De nuevo (sorry), no sabes el nombre del host virtual, porque ese viene en el encabezado de la peticion del HTTP y esa conexion aun no se da. > El servidor sólamente puede mandar un certificado por cada combinación de host y > puerto mientras que el DNS te puede resolver un número indefinido de hosts que apunten > hacia la misma IP y si tu host virtual escucha en el puerto 443 (el default) no > necesitas poner el puerto en la URL. > De ahí que si dos o más hosts te resuelven la misma IP y pudes en la URL cada uno de > esos hosts, sólamente el que concuerde con el CN del certificado te va a dejar pasar > sin que tu cliente proteste. De ahí que Gunnar tiene razón cuando dice ' Sí, vas a > poder usar los > > hosts virtuales, pero tu navegador se quejará de que el certificado no > > corresponde y hará pensar al usuario en posibles ataques de > > personificación de terceros.'; > > > But in order to dispatch to the correct virtual server > > Apache has to know the Host HTTP header field. Va a establecer la conexion usando la IP y el apache va a tomar el primer nombre de servidor que encuentre en su archivo de configuracion con esa IP. Los virtual host por nombre no tienen una IP asignada, usan la de "default" > Eso no lo conoce hasta después de que terminó la negociación de SSL y ya puede > comenzar a pasar el http dentro del SSL. > > > For this the HTTP request > > header has to be read. This cannot be done before the SSL handshake is > > finished. But the information is already needed at the SSL handshake > > phase. Bingo! > > La información que se necesita para el handshake del SSL no la puede tomar del host > virtual, entonces la toma del par IP/puerto que concuerde de la lista de los que ya > tiene cargados desde que arrancó. Eso te funciona cuando tienes los virual hosts por IP. > Bueno, como todo esto es muy confuso se me ocurrió hacer una demostración de lo que > decía Gunnar sobre la queja del cliente que recibe un certificado malo con la > siguiente tercia de hosts virtuales que apuntan hacia la misma IP y te redirigen hacia > la misma IP en el mismo puerto: > http://bueno.prueba.sip.gob.mx/ > http://malo.prueba.sip.gob.mx/ > http://www.prueba.sip.gob.mx/ <-- es muy acostumbrado poner un ServerAlias con la > versión www del sitio y lo que sucede no es bueno. > Despues de tanto rollo, lo mejor es hacer la prueba, muy bien por la demo. Para hacer una prueba ponle https y no http y luego checate que el certificado que te envia en los tres casos es el mismo, p.e. viendo el serial number que es 01. No esta pelando el nombre de los virtual hosts y esta usando en del primario, por lo que envia elk certificado de este. Seria bueno que pusieras por ahi el cacho del archivo http.conf donde los tienes declarados para ver como estan. Que esta pinche que asi funcione, sin duda, pero pues ni pex. Le han tratado de dar la vuelta, pero hasta donde yo se, no hay vuelta de hoja. saludos Eduardo Sacristan _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/