meerdere SSL certificaten met één ip

[Trax_Digitizer]

Na wat zoekwerk op internet en GoT ben ik al verschillende howto's en vragen omtrent het self-signen van SSL certificaten en het configureren van apache. Over het onderstaande kom ik echter niet zoveel (eigenlijk nog niks) tegen. Ik ben benieuwd naar jullie meningen.

Het is inmiddels bekend dat het met een virtual hosting server met maar één extern ip-adres niet mogelijk is om meerdere domeinen (virtual hosts) van SSL te voorzien. Dit kan maar met één host per ip-adres, omdat de routering op basis van virtual hosts afhankelijk is van host-informatie in de HTTP header. En het eerste HTTP pakketje komt pas over de lijn op het moment dat de SSL verbinding is opgezet (dat is namelijk de gedachte achter encryptie). Kortom, de server kan niet weten welke (domein-afhankelijk) certificaat hij moet gebruiken om de verbinding op te zetten.

Dit laatste statement zou ik graag eens ter discussie willen stellen. Wanneer ik tshark (commandline versie van wireshark) gebruik om https verkeer te monitoren valt het me opnamelijk op dat het derde frame (Handshake Protocol: Client Hello) altijd in plain text de hostnaam bevat van het domein waarmee je op dat moment een ssl verbinding gaat opzetten. Dit frame gaat van de client (degene die een SSL verbinding wil opzetten) naar de server (degene met meerdere certificaten). En dan laat ik me zonder verder onderzoek te verrichten even verleiden tot het doen van de volgende uitspraak: Als het inderdaad altijd zo is dat de hostname tijdens de SSL handshake plain text wordt vernoemd in het bericht, dan moet het ook mogelijk zijn om op basis hiervan het juiste certificaat te selecteren.

En dan meteen maar even kritisch naar mezelf toe. Ik twijfel aan deze uitspraak omdat ik me dan afvraag hoe alle vervolgpakketten gerouteerd gaan worden? Routering gebeurd namelijk op laag 3 van OSI en SSL zit op laag 6. Is dit dan ook meteen de reden dat het niet zal gaan werken, of is daar een andere reden voor.

Verder vraag ik me af of een SSL offloader hier uitkomst kan bieden. Bij mijn weten kan een SSL offloader ook geen SSL routeren. Hij kan alleen SSL sessies opzetten en dan door-routeren op basis van hostname in HTTP header. Het door routeren gebeurd dan eventueel weer over een nieuwe SSL verbinding. Toch?

Kan dit dan toch echt alleen wanneer elk domein een eigen ip OF poortnummer heeft?

[Osiris]

Check SNI eens. Werkt alleen in 'moderne' browsers, dat dan wel weer.

Trax_Digitizer schreef op donderdag 07 augustus 2008 @ 18:08:
En dan meteen maar even kritisch naar mezelf toe. Ik twijfel aan deze uitspraak omdat ik me dan afvraag hoe alle vervolgpakketten gerouteerd gaan worden? Routering gebeurd namelijk op laag 3 van OSI en SSL zit op laag 6. Is dit dan ook meteen de reden dat het niet zal gaan werken, of is daar een andere reden voor.

Mag jij mij vertellen wát er precies geroute wordt. En wat dat in vredesnaam met de Host-HTTP-header te maken heeft

[ Voor 68% gewijzigd door Osiris op 07-08-2008 18:19 ]

[PipoDeClown]

middels de sslv3(.1) extensie Subject Alternative name (ofzoiets) kun je je certificaat definieren voor welke hosts die geldig is.

[Trax_Digitizer]

Hmm dat is interessant. Als de server én de browser aan bepaalde eisen voldoen, is het dus wél mogelijk meerdere certificaten i.c.m. virtual hosting vanaf één ip aan te bieden over de standaard poort 443. Voor alledaags gebruik op internet is het dus minder geschikt omdat je met zekerheid kunt stellen dat lang niet alle browsers aan die specifieke eisen voldoen, maar in een private infrastructuur biedt dit mogelijkheden.

Dit:

An extension to TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual host as part of the TLS negotiation[1]. This enables the server to "switch" to the correct virtual host early and present the browser with the certificate containing the correct CN.

is inderdaad wat ik bedoel. Op deze manier vervalt de afhankelijkheid van de HTTP host header. En aan de reactie van PipoDeClown te zien kan dat inderdaad op meerdere manieren.

En vervolgpakketten (--state ESTABLISHED,RELATED) zijn er natuurlijk niet, omdat het dezelfde machine betreft die na opzetten van de SSL sessie de HTTP pakketten die eroverheen gaan kan routeren op basis van de HTTP host header. En wanneer een SSL sessie gerouteerd moet worden naar een andere server in het netwerk is er natuurlijk gewoon sprake van NAT.

[Osiris]

Trax_Digitizer schreef op donderdag 07 augustus 2008 @ 18:41:
En vervolgpakketten (--state ESTABLISHED,RELATED) zijn er natuurlijk niet, omdat het dezelfde machine betreft die na opzetten van de SSL sessie de HTTP pakketten die eroverheen gaan kan routeren op basis van de HTTP host header. En wanneer een SSL sessie gerouteerd moet worden naar een andere server in het netwerk is er natuurlijk gewoon sprake van NAT.

Euhm, 'plain' routen gaat op basis van IP's en NAPT gaat op basis van IP's + TCP/UDP-poortnummer. 't Houdt dus op bij OSI-layertje 4 (TCP/UDP) en heeft verder niets met SSL te maken.

[Trax_Digitizer]

Precies, dat bedoelde ik ook met mijn laatste regel uit mijn vorige post. Ik zat hier even wat dingen door elkaar te gooien.

[Trax_Digitizer]

Vraag me nog één ding af. Is SNI nu hetzelfde als de TLS extension "server_name"?

Quote RFC3546:

It is RECOMMENDED that clients include an extension of type "server_name" in the client hello whenever they locate a server by a supported name type.

A server that receives a client hello containing the "server_name" extension, MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy.

Quote Wikipedia:

An extension to TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual host as part of the TLS negotiation[1]. This enables the server to "switch" to the correct virtual host early and present the browser with the certificate containing the correct CN.

Ik krijg sterk de indruk dat er over hetzelfde wordt gesproken maar dan met een andere naam.

[Osiris]

Ja en nee. De "techniek" heet SNI heb ik het idee (voor in de "volksmond" ofzo), maar de daadwerkelijke "feature" in 't TLS-protocol-gebeuren heet "server_name". Ik heb net eventjes met Wireshark een HTTPS-site-bezoekje gecaptured en die geeft altijd leuk wat informatie per protocol. En daar heet het ook "Extension: server_name" met vervolgens de hostname in plain-tekst.

[ Voor 3% gewijzigd door Osiris op 08-08-2008 09:14 ]

[Trax_Digitizer]

Klopt, ik gebruik zelf ook wireshark om te testen. Je ziet ook dat het vanuit windows XP met Firefox (3.0.1) wél erin staat, maar met IE7 niet. Met IE7 werkt het namelijk alleen in vista.