Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Nieuwe SSL sleutel xs4all?

13-05-2012, 10:55 door Fwiffo, 4 reacties
Het viel mij gisteren bij een andere xs4all gebruiker op dat de sleutel van de webmail anders was (nieuwe en oude webmail):
Issued By Common Name (CN): GlobalSign Domain Validation CA - G2
SHA1 Fingerprint: 09:42:30:B9:CA:0F:BD:DF:B3:FC:8F:1E:8E:10:B0:0E:4C:D2:F4:A1

Het Service Center heeft nog:
Issued By Organizational Unit (OU) : Equifax Secure Certificate Authority
SHA1 Fingerprint: 0B:17:5D:53:4D:6D:2F:8C:CE:D2:82:89:95:E8:EE:3F:E7:D5:97:FD

Sorry voor typo's, Firefox laat me niet copy-pasten hier :-/
Reacties (4)
13-05-2012, 11:10 door Anoniem
Kijk eens naar de datum van uitgifte
13-05-2012, 12:32 door Fwiffo
Door Anoniem: Kijk eens naar de datum van uitgifte
4 mei dodenherdenking. Maakt het mysterie niet minder voor mij. Het vorige certificaat was nog lang niet verlopen (22 september 2016)...
16-05-2012, 15:37 door Nimrod
De sleutel hoeft helemaal niets anders te zijn. Het lijkt erop dat er twee verschillende CA's een certificaat hebben uitgegeven aan xs4all. Dit betekent dat onder andere de CN, CA en dergelijke verschillende zijn. De sleutel zou in theory echter wel hetzelfde kunnen zijn. Dit kan je ook gewoon met elkaar vergelijken.

De Sha1 Fingerprint is een hash van het gehele certificaat. Dus met de sleutel en alle informatie bij elkaar.

Het lijkt me overigens helemaal niet vreemd dat er een nieuw certificaat is uitgegeven voor de nieuwe webmail. Een certificaat is namelijk vaak verbonden aan een domeinnaam. Zo zou het kunnen dat het oude certificaat is uitgegeven voor mail.xs4all.com en het nieuwe voor mailv2.xs4all.com.

Snappie?
16-05-2012, 23:18 door Erik van Straten
https://service.xs4all.nl/ (194.109.6.122): Subject: *.xs4all.nl
CA: Globalsign
Geldig van 2012-05-04 t/m 2017-07-07
public key size=2048 bits
Eerste 4 bytes van de modulus van de public key: c0 26 7a 2a
SHA1 fingerprint: 0b 17 5d 53 4d 6d 2f 8c ce d2 82 89 95 e8 ee 3f e7 d5 97 fd
https://roundcube.xs4all.nl/ (213.222.31.25) en https://webmail.xs4all.nl/ (194.109.6.100): Subject: *.xs4all.nl
CA: Equifax
Geldig van 2010-08-22 t/m 2016-09-22
public key size=2048 bits
Eerste 4 bytes van de modulus van de public key: da 0e e6 99
SHA1 fingerprint: 09 42 30 b9 ca 0f bd df b3 fc 8f 1e 8e 10 b0 0e 4c d2 f4 a1
Ik gok dat xs4all risico's aan het verlagen is door wildcard certificaten bij twee verschillende CA's af te nemen:

- In het scenario dat één van die CA's gecompromitteerd raakt (zoals Diginotar vorig jaar) dan hebben alle xs4all SSL servers die certificaten ondertekend door de andere CA inzetten (ik vermoed de helft van hun SSL servers), geen probleem. Op de andere helft van hun servers kan xs4all, per server, dan volstaan met het vervangen van de private key en certificaat. Daarmee zijn ze niet meer afhankelijk van 1 enkele CA en hebben geen last van grote doorlooptijden bij het aanvragen van nieuwe certificaten!

- In het scenario dat een xs4all SSL server gecompromitteerd raakt, en niet kan worden uitgesloten dat de private key is gekopieerd, zullen ze het bijbehorende certificaat moeten intrekken. De consequentie daarvan is dat ze een probleem hebben op (vermoed ik) de helft van hun servers. Op die servers waarvan ze zeker weten dat deze niet gecompromitteerd zijn, kunnen ze weer het andere certificaat + private key installeren. Overigens zou het me niet verbazen als de private keys niet op de betreffende servers zelf staan maar in nagenoeg ontoegankelijke HSM's (zie http://en.wikipedia.org/wiki/Hardware_security_module) zijn ondergebracht, en daarmee het risico op dit scenario erg laag is.

Ik kan me niet voorstellen dat de aanschafkosten een grote rol hebben gespeeld bij de keuze voor wildcard certificaten (*.xs4all.nl) in plaats van unieke per-server certificaten. Aan de andere kant, door 2 wildcard certificaten te gebruiken, wordt het beheer er wel een stuk eenvoudiger door (je hebt maar 2 private keys en 2 certificaten en welk setje je op een server zet maakt niet uit). Een andere verklaring heb ik niet. Iemand anders wel misschien?

Tip voor beheerders met meerdere SSL servers die in principe van een wildcard certificaat gebruik zouden kunnen maken (ook al doen ze dat nu niet): zorg dat je altijd een wildcard certificaat (gebaseerd op een uniek keypair) van een andere CA op de plank hebt liggen. Gaat je eerste CA "titsup" (http://www.channelregister.co.uk/Tag/Titsup) dan ben je snel weer in de lucht met je wildcart cert!
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.