omdat asnbank niet hetzelfde is als snsbank

Dat snap ik, maar - - - hoe erg - - - is het, en waarom?

Het is erg slecht, omdat er een certificate mismatch ontstaat. Feitelijk is het niet zo'n punt, aangezien SNS een onderdeel is van ASN. Kijk maar eens naar de reclame over hypotheken. SNS adviseert niet alleen eigen hypotheek. Alle getoonde andere hypotheeknemers zijn allemaal onderdeel van ASN. Mogelijk kom je in hun certificaat keten hetzelfde probleem tegen.

Niet erg, doordat de browser automatisch het certificaat selecteert dat het moet hebben, dus dat van sns. Ik snap alleen niet waarom dat certificaat van asn aan sns is gekoppeld. Dat lijkt me nergens goed voor.

Misschien kijk ik er overheen, maar in de link die je geeft zie ik geen vuurrode "MISMATCH" bij certificate #2.

Ik weet wel zeker dat je er overheen kijkt:

Je hebt gelijk, mijn excuses!

Ik weet nog niet zoveel van TLS v1.3, maar zo te zien is dit een nieuwe feature van dat protocol.

Zo te zien ondersteunt de webserver op of achter IP-adres 194.53.208.72 (van www.snsbank.nl) ook de website van www.asnbank.nl, want als ik in mijn hosts file opneem:
in in mijn browser https://www.asnbank.nl/ open, dan wordt die site getoond zoals verwacht (d.w.z. als ik zonder die regel naar https://www.asnbank.nl/ surf - dan kom ik op 194.53.208.80). Met deze regel in de hosts file zie ik in Wireshark dat er daadwerkelijk met 194.53.208.72 wordt gecommuniceerd (en zonder die regel met 194.53.208.80).

Echter ik zie in Firefox (ESR v78.6.1 ESR) nergens dat er daadwerkelijk twee server-certificaten zijn meegestuurd. Ook in Wireshark zie ik dat niet t.g.v. TLS v1.3.

Als ik in Firefox TLS v1.3 disable (TLS v1.2 als hoogste opneem) zie ik in Wireshark alleen het server-certificaat voor de betreffende site (op basis van SNI) gestuurd worden.

Er verder over nadenkend: ik vermoed dat dit gedrag nodig is omdat de SNI (Server Name Indication) informatie met TLS v1.3 niet meer zichtbaar verstuurd mag worden, maar natuurlijk ook niet naar een andere server dan bedoeld. Ik moet toch maar eens in die TLS v1.3 docs duiken.

Om op jouw vraag terug te komen: het lijkt mij totaal niet erg. De browser kan kiezen welk server-certificaat (feitelijk welke chain) deze accepteert, op basis van het domein waar jij naar toe wilt. In elk geval Firefox ESR lijkt hier geen problemen mee te hebben, en vermoedelijk andere browsers die TLS v1.3 ondersteunen, ook niet.

Overigens wel opmerkelijk dat hier op ssllabs nog geen opmerking over staat.

Dank voor jouw vraag, ik heb weer wat geleerd en weer iets aan mijn todo-lijst toegevoegd!

Er is niks mis mee.
Dit is een site die met SNI werkt. Alleen als je browser geen SNI ondersteunt (jaar kruik browser) gaat het mis want
dan krijgt hij het certificaat van ASN bank. Dan zul je dus een warning krijgen maar als je die negeert zul je waarschijnlijk
op de ASN bank site uitkomen.

Het was wellicht netter geweest om als default site een nikszeggende lege "Apache is geconfigureerd" site neer te zetten
ipv iets wat een bank site is, maar er is verder niks stuk ofzo.

Bedankt voor je reactie van 16:40 Erik. (en ook de anderen die hebben gereageerd bedankt)
Mij viel net nog op dat het "mismatched" certificaat eigenlijk het certificaat is voor www.asnbank.nl gelet op de sha256- fingerprint ervan. Echter voor www.asnbank.nl is er uiteraard geen sprake van een mismatch in de tenaamstelling in dit certificaat.

Verder valt op dat www.asnbank.nl geen gebruik maakt van SNI, en www.snsbank zo te zien wel.
Of dat iets met de mismatch-melding te maken heeft weet ik niet, maar ik sluit het niet bij voorbaat uit.

Ik vermoed voorzichtig dat het een kwestie van interpretatie is, en dat ssllabs zo'n situatie niet helemaal goed interpreteert zodat het algoritme van ssllabs onterecht een verband legt tussen "www.snsbank.nl" en dat tweede "mismatched" certificaat dat eigenlijk bedoeld is voor www.asnbank.nl. (en dus eigenlijk niets met www.snsbank.nl te maken heeft)

Maar mocht jij hierover nog meer details boven water kunnen krijgen, dan hoor ik het natuurlijk graag.

Je vraagt een beetje naar de bekende weg.

Dit betekent dat het certificaat niet bij het domein hoort, en dus ongeschikt is voor een vertrouwensrelatie.

Naast dat mensen op het verkeerde been gezet worden (Is het gehackt?) is het ook zo dat diverse leach-tools niet werken. In het laatste geval wordt de website mogelijk als fraudulent aangemerkt, of zelfs als compromised. Het domein/ip kan dan op een blacklist terecht komen. Dit kan een grote impact hebben als er ook e-mail verkeer vandaan gestuurd wordt.

Gebeurt meestal als je bijvoorbeeld een F5 loadbalancer ervoor zet en maar 1 batterij van die krengen voor al je merken gebruikt.
Netjes? Nee... efficient? Jep.

Welnee, allemaal kwatsch. Als je gewone spullen gebruikt dan werkt het gewoon. SNI bestaat al een tijdje, als je
dat niet hebt dan loop je wel behoorlijk achter met je updates.
En of je bejaarde leach-tools niet werken dat zal een bank echt worst wezen!

Op https://github.com/ssllabs/ssllabs-scan/issues/476 legt SSLLabs het helemaal uit.

Heb je er ooit last van? Nee. Want een moderne browser connect altijd over Server Name Indication (SNI) en dan scoren ze een A+ voor de config. Heb je zo een oude browser dat SNI niet werkt (IE6 op XP) dan krijg je over TLS 1.2/1.3 toch geen connectie. Vraag me bijna af waarom SSLLabs nog zonder SNI test.

Je ziet trouwens exact hetzelfde op de domeinnaam van het NCSC (Nationaal Cyber Security Center) ncsc.nl, waar de zonder SNI variant uitkomt bij platformrijksoverheid.nl:
https://www.ssllabs.com/ssltest/analyze.html?d=www.ncsc.nl&s=178.22.85.148

Beide TLS verbindingen lijken netjes ingericht te zijn volgens de richtlijnen die staan op https://www.ncsc.nl/onderwerpen/verbindingsbeveiliging.

thx, leerzaam :-)

@Anoniemen 17:16 en 17:44, voor de duidelijkheid: tijdens de test door ssllabs ontvangt deze, van 194.53.208.72 (dat adres krijg je na een DNS lookup van www.snsbank.nl) twee onafhankelijke certificate chains:

1) een geldig server-certificaat voor www.snsbank.nl (tevens voor snsbank.nl, www.sns.nl en sns.nl) plus een intermediate certificaat "DigiCert SHA2 Extended Validation Server CA";

2) een geldig server-certificaat voor www.asnbank.nl (tevens voor asnbank.nl, www.asn.nl, asn.nl en beleggingsfondsen.asnbank.nl) plus een intermediate certificaat "DigiCert SHA2 Extended Validation Server CA".

In elk geval in Firefox ESR (en Firefox v.84.1.4 onder Android) leidt het openen van https://www.snsbank.nl/ niet tot foutmeldingen of waarschuwingen, waarbij ik op moet merken dat ik nog niet heb kunnen vaststellen dat Firefox (met TLS v1.3 enabled) daadwerkelijk beide certificate-chains ontvangt. Welke request ssllabs precies naar die server stuurt (wel/geen SNI of ESNI) dat dit in twee chains resulteert, weet ik niet. En dus ook niet of deze request hetzelfde is als wat Firefox ESR via TLS v1.3 verstuurt.

Duidelijk is wel dat 194.53.208.72 zowel https://www.snsbank.nl/ als https://www.asnbank.nl/ ondersteunt (dat heb ik aangetoond door een tijdelijke aanpassing van de hosts file op mijn PC, waardoor Firefox geen DNS lookup doet en ervan uitgaat dat www.asnbank.nl als IP-adres 194.53.208.72 heeft). Daarbij kreeg ik, zonder certificaat-foutmeldingen, de verwachte homepage van www.asnbank.nl te zien. Het is dus waarschijnlijk niet zo dat de server met dit IP-adres verkeerd geconfigureerd is met een overbodige certificate-chain voor asnbank.nl (die site zit wel degelijk ook achter dit IP-adres).

Interessant is dat ssllabs uitsluitend de tweede hierboven genoemde certificate-chain ontvangt (van 194.53.208.80) als ik https://www.ssllabs.com/ssltest/analyze.html?d=www.asnbank.nl&hideResults=on bekijk. De server voor dat IP-adres lijkt dus, naast voor asnbank.nl, niet tevens voor snsbank.nl te kunnen worden gebruikt.

Gokje: misschien is er sprake van een testsetup op die *.80 en volgt *.72 later (d.w.z. dat ook *.72 beide websites gaat ondersteunen en dus twee certificate-chains mee gaat sturen).

Nee hoor!!! Goed lezen. Dat tweede certificaat krijgen ze alleen als ze geen SNI meesturen.
Dat is uiteraard niet wat een browser krijgt. Die stuurt WEL SNI mee.

Die site doet allerlei testen ook dingen die normaal niet gebeuren. Daardoor gebeuren er dingen waar je normaal
gesproken niet mee te maken hebt. Dat blijkt ook wel uit het feit dat ze evengoed een A+ waardering aan die site
hangen, dat zouden ze zeker niet doen als er problemen waren.

De server van NCSC.nl (Nationaal Cyber Security Center) doet exact hetzelfde: het heeft op SNI ook een A+ en zonder SNI een certificaat van 'platformrijksoverheid.nl'.

Op https://github.com/ssllabs/ssllabs-scan/issues/476 legt SSLLabs uit waarom dat zo werkt.

Dat viel mij ook op. Ik gebruik een nas waar verschillende sites op staan via een virtual host. De nas heeft een default certificaat en de sites gebruiken een eigen certificaat dia aan de virtual host gekoppeld is. Een gebruiker ziet in de browser alleen het certificaat voor de site.

Als ik een van mijn test sites analyseer met ssllabs, dat toont ssllabs als certificaat #1 dat van de nas en als certificaat #2 dat van de site zelf. Dat #1 certificaat wordt niet eens gebruikt voor de site. Volgens mij ondersteunt elke browser SNI, want anders waren een heleboel sites gewoon niet te bereiken. Het eerste data pakketje vertelt onversleutelt welke site hij wil bezoeken, dus hoeft het certificaat van de server zelf ook niet gebruikt te worden. Via TLS 1.3 is er ook een gecodeerd sni pakketje mogelijk, maar wat ssllabs laat zien gebeurd ook bij niet TLS 1.3 sites.

Zo'n server certificaat van een server waar meerdere sites een IP delen, kun je volgens mij opvragen met het commando:


Bij een enkelvoudige site zie je het certificaat van de site en bij een gedeelde site het certificaat van de onderliggende server.

Zelf gewerkt bij een ICT-bedrijf dat domain-services leverde. De kwaliteit van configuratie heeft zeker impact op de reputatie van je domein, bijv. door ranking in Google of Bing. En het maakt dan wel degelijk uit of je website gevonden wordt op pagina 1 of 2 van een google/bing search. Dit laatste kan een veelvoud aan bezoekers verschillen.

Dus niet kwatsch!

Hier een geval met hetzelfde euvel:
https://forum.openlitespeed.org/threads/there-is-a-problem-in-setting-multiple-dedicated-ssl-for-two-different-domains.3868/:

De site van deze bank staat heel duidelijk op pagina 1.
Dus deze config maakt de zoekmachines ook niets uit.

Ah, nu zie ik het ook. Het tweede certificate blok op de pagina begint met de tekst:
Die laatste "No SNI" (hier onderstreept door mij) staat op de ssllabs pagina in oranje letters. Daar heb ik steeds overheen gekeken, sorry.

Overigens begrijp ik het nut van deze test niet (die mij nooit eerder is opgevallen - maar ik kijk wel vaker met mijn neus |-). Met de alleen maar toenemende schaarste aan IPv4 adressen -en de wens die te gebruiken- is SNI immers onvermijdelijk.

Misschien de volgende keer als je op de aangewezen pagina bent aangekomen even <control-F> doen,
en daarna "sni" intikken en vervolgens <Enter>?... ;-)

SNI loopt via de TLS-layer, en de andere methode loopt via de HTTP-layer.
Bij truuks als "Domain fronting" kan het handig zijn dat het op ssllabs is te controleren of het allemaal goed staat ingesteld.

Dit "ranking in Google of Bing" dat interesseert zo'n bank echt niet hoor! Die staan toch wel bovenaan en anders
kopen ze die positie gewoon. Dit is alleen van belang voor bedrijfjes die proberen te verdienen aan "google ranking
verbetering" (= parasiteren op de onwetendheid van eigenaren van kleine sites).