“Weinig Nederlandse webwinkels gebruiken SSL certificaten”

[quote]Voor elk SSL-certificaat is een uniek IP-adres nodig en dat terwijl IPv4 adressen telkens schaarser worden. Gaat SSL daarom de killerapp worden voor IPv6?[/quote]

Onder Apache is bij gebruik van SSL een uniek IP-adres nodig. Onder IIS kunnen meerdere SSL sites gebruik maken van 1 ip.

Juist...

Als klopt wat Ras stelt moet elke site waar een gebruiker persoonsgegevens achterlaat met SSL worden versleuteld. Dit beperkt zich dan mijns inziens niet tot webwinkels.

@ Lamp, naar mijn idee niet? De headers worden ook encrypted verstuurd, dus de webserver weet pas om welke "Host:" het gaat nadat de SSL connectie is opgezet?

Ik heb niet veel ervaring met IIS, dus correct me if i am wrong.

@Wido

Capture maar eens de pakketjes naar een https:// adres (maakt niet uit of je apache of IIS) gebruikt. Dan zul je daarin zien dat de hostheader eenmalig in leesbaar formaat lang komt.

Nu IIS en apache anders in elkaar zitten met security. IIS doet deze leesbare info om te bepalen welk cert die moet gebruiken, apache gebruikt deze info niet (omdat deze fake kan zijn). Veilig onveilig... Als de info niet klopt zal er een verkeerde cert door IIS gebruikt worden en klopt de cert niet bij de hostheader (al kan de verzonden info anders zijn dan de info op het scherm). En apache schuift het af op de DNS, de DNS moet de juiste ip maar bij de hostnaam terug geven waardoor apache het op IP kan configgen.

Voor beide applicaties een implentatie keuze met ieder voor- en nadelen. Uiteindelijk moet de gebruiker blijven controlleren welke cert er gebruikt wordt ;)

Het is niet mogelijk, ik zou niet weten hoe.

Technisch volgens mij is het zo goed als onmogelijk.

Zelfs in de FAQ op de Microsoft site (aangezien we het over IIS hebben) staat:

"If the client requests an SSL connection, the Host Header field is still included, but contained in the encrypted part of the packet (in the application layer), so it cannot be decrypted by the web server in order to determine which web site the request should be routed."

"This creates an unbreakable rule: You cannot use Host
Headers as the primary means of identifying a web site when using SSL. I don't care what else you've heard, this is the case."

Ik kan me maar 1 ding voorstellen, dat misschien zou kunnen, 2 sites beide subdomeien van het zelfde domein met het zelfde ssl-certificaat dat een wildcard heeft op 1 IP-adres.

[quote]
Lennie op 20 November 2007 20:43:38

Het is niet mogelijk, ik zou niet weten hoe.[/quote]

Ik leg net uit dat de hostheader _un-encrypted_ over de lijn gaat. En als je dat niet wil geloven capture je zelf maar een aantal pakketjes van de communicatie naar een SSL site.

En als je dat dan verder nog echt niet wil geloven, dan mail je maar 2 certs om, plaats ik die wel op een IIS, waarbij de IP's de zelfde adressen zullen zijn.

En voor de rest van de eigenwijze mensen verwijs ik naar:
RFC3546 (http://www.ietf.org/rfc/rfc3546.txt)
3.1. Server Name Indication (SNI)

En kom nu niet zielig aan dat jou browser of andere applicatie geen TLS extensions aankan. We lever niet meer in de prehistory...

En tevens een apache module om dit alles ook onder apache mogelijk te maken:
http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

Ik heb even voor je gekeken, IE6 op Windows XP/2003 is dus prehistorie, begrijp ik ?

Ik denk nog niet dat we zo ver zijn.

@Lennie:
Ja, IE6 is history... IE7 komt al als critical updates bij windows update mee.

Ik dacht ik zal voor de volledigheid IE7 ook nog even testen. Ja die gebruikt wel TLS ipv. SSLv2, maar die gebruikt de server_name-extensie ook niet.

Welcome to the world of sucking IE, deal with it, I deal with it every day (doe namelijk voornamelijk web-applicaties bouwen).

De Microsoft-browser leeft nog in de stone-age.

@Lennard:
IE6 en eerder worden nog door veel mensen gebruikt. Het is uiteindelijk ook voor een groot deel de gebruiker die bepaald of er omgeschakeld kan worden mijn inziens. Ik ken nog genoeg mensen die met windows versies van voor windows XP werken (ook bedrijven) en probeer daarop maar eens IE7 te installeren via windows update...

Als je het daar niet mee eens bent adviseer ik je vast volledig over te gaan op IPv6.

@Lennie
Dan hebben we een verschillende IE7 versie (of config). Mijn IE7 doet namelijk wel de SNI extensions gebruiken.

IE6 wordt inderdaad nog veel gebruikt en dus alle opmerkingen dat het _nog_ niet te gebruiken is klopt dat ook. Echter was er in het begin de twijfel of het technisch mogelijk was.
Technisch is dus geen probleem om het op te lossen.

De killapp merking in het orginele verhaal is dus geen goed argument. Ik zie de huidige apps (als voorbeeld IE6) eerder vervangen worden voor nieuwe versies door (eind)gebruikers, dan dat die zelfde (eind)gebruiker een migratie naar ipv6 gaat doen.

@Lennard:

Het is wel mooi dat het technisch wel kan, ik was niet op de hoogte van die ontwikkeling. Je levert ook niet veel in privacy gebied als de hostheader wel un-encrypted is. Want normaal gesproken is het 1 site per IP-adres, dus welke site je bezoekt is toch al duidelijk.

Bij de weg: het is Windows 2003 met laatste updates tot afgelopen zaterdag, althans ik zie het niet in de pcap. Ter informatie:

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)

@Lennie:
Dat lijkt veel op Mozilla Firefox (geen IE7 ten minste).

We kregen vandaag van SSL.nu een (relatief aggresieve vorm van) mailing. Hierin werd beweerd dat onze site (overigens een oud domein dat geredirect wordt) niet beveiligd was.
Onze site is echter wel degelijk beveiligd met een (Extended Validation!) SSL certificaat van VeriSign zélf. Tevens is de VeriSign 'secure' badge duidelijk weergegeven opgenomen in onze site. Dit kan niet gemist worden.

Dat 'onderzoek' dat gepleegd is bleek, na een boos telefoontje, niets meer te zijn dan een dump uit (erg oude) iDeal gegevens (hoe ze daar aan komen mag joost weten). Het onderzoek is dus kul; dit is gewoon een goedkope manier van SSL.nu om reclame te maken.