Redphex
LegendRabbitOfNegativeEuphoria
|
Auf einer meiner Webseiten hab ich SSL Pinning aktiviert,
der Qualys SSL Test ist auch mit der Konfiguration zufrieden.
In der Firma betreiben wir einen Proxy mit SSL breakup - den lässt das völlig kalt und auch ein Kurztest mit SSL Inspection durch den Virenscanner (selbes Prinzip) lässt den Zugriff zu.
Das ist nicht wirklich, was ich erwartet hätte. Versteh' ich was falsch, oder sind Konfigurationsfehler möglich, die dem Test nicht auffallen?
Bearbeitet von Redphex am 24.03.2016, 19:00
|
Smut
takeover & ether
|
was verstehst du unter pinning?
hpkp?
prinzipiell nicht von allen browsern unterstützt. ein ssl interception proxy wird das denke ich aber einfach rauswerfen. der client kann es nur checken wenn er bereits zuvor eine direkte verbindung ohne mitm aufbauen konnte.
|
Redphex
LegendRabbitOfNegativeEuphoria
|
ja, HPKP.
Ich habs mit FF getestet - den verwende ich normalerweise direkt.
Dann schalte ich den Proxy dazwischen und trotzdem wurscht?!
|
Smut
takeover & ether
|
wenn du den proxy dazwischen hast:
von welcher root-zertifikat wird die certificiate chain gebuildet?
von der des interception proxy oder von der letsencrypt. wenn es die letsencrypt ist, hat der interception proxy die verbindung 1:1 durchgestellt.
wenn es die root des interception proxys ist, dann funktioniert HPKP nicht so wie es soll
|
TOM
Super ModeratorOldschool OC.at'ler
|
Meine Verständnis nach sollte der SSL-Interceptor (Proxy) dazwischen funktionieren, egal ob Cert-pinning oder nicht
Für den Server ist ja der SSl-Interceptor der "Endkunde" und da wird sicher gestellt, dass das richtige Zertifikat vorhanden ist und kein falsches untergejubelt wird (Pinning).... der eigentliche Client sieht ja nur das Zertifkat vom SSL-Interceptor und bekommt vom eigentlichen SSL-Zertifikat mit pinning garnichts mehr mit.
Der Proxy vertraut dem SSL-Pinning und dein Client vertraut dem (wohl intern ausgestellten Wildcard-)Zertifikat.
Sonst würde es ja auch extrem viel zusammenhauen.... nutzt ja schon fast jeder solche SSL-breakups
Bearbeitet von TOM am 24.03.2016, 15:52
|
Redphex
LegendRabbitOfNegativeEuphoria
|
wenn es die root des interception proxys ist, dann funktioniert HPKP nicht so wie es soll Sehe ich auch so. Nur was ist falsch?  an sich bin ich dieser Anleitung nachgegangen: http://www.my-it-brain.de/wordpress...ning-mit-nginx/ - so viele Stolpersteine gibts ja nicht und wie gesagt der SSL Test meint alles ist gut ...
Bearbeitet von Redphex am 24.03.2016, 15:53
|
Redphex
LegendRabbitOfNegativeEuphoria
|
@Tom - bin mir da nicht ganz sicher.
zB. haben Kollegen für die Benutzung von diversen Apps extra von mir Ausnahmeregeln am Proxy bekommen, die die SSL-Verbindungen direkt ohne Breakup durchtunneln, weil sonst nix geht.
|
Smut
takeover & ether
|
Sehe ich auch so. Nur was ist falsch?
an sich bin ich dieser Anleitung nachgegangen: http://www.my-it-brain.de/wordpress...ning-mit-nginx/ - so viele Stolpersteine gibts ja nicht und wie gesagt der SSL Test meint alles ist gut ... wurde die verbindung also wirklich aufgebrochen? - dein browser erhält das zertifikat vom proxy? @TOM: ist das wirklich so üblich? bei .us firmen ja. ich kenne aber keine firma in .at die das macht obwohl ich in dem bereich tätig bin. wenn sie es machen dann in ganz bestimmten anwendungsfällen, nicht aber bei z.b. zentralen break-outs für user traffic
|
Redphex
LegendRabbitOfNegativeEuphoria
|
Ich hab die Ursache in der FF Konsole gefunden: Public-Key-Pins: The certificate used by the site was not issued by a certificate in the default root certificate store. To prevent accidental breakage, the specified header was ignored. mit security.cert_pinning.enforcement_level=2 verhält sich FF so, wie ich es erwarten würde (Meldung: The server uses key pinning (HPKP) but no trusted certificate chain could be constructed that matches the pinset. Key pinning violations cannot be overridden.)
|
TOM
Super ModeratorOldschool OC.at'ler
|
wurde die verbindung also wirklich aufgebrochen? - dein browser erhält das zertifikat vom proxy?
@TOM: ist das wirklich so üblich? bei .us firmen ja. ich kenne aber keine firma in .at die das macht obwohl ich in dem bereich tätig bin. wenn sie es machen dann in ganz bestimmten anwendungsfällen, nicht aber bei z.b. zentralen break-outs für user traffic Ich hatte bisher nur mit zentralen Client-Proxies zu tun, die den SSL-Traffic aufgemacht haben (in den Firmen wo ich tätig bin/war) Wo würden wir denn sonst hinkommen, wenn sich jeder Mitarbeiter verseuchten **** runterladen könnte  (und ich muss zugeben mit key-pinning habe ich noch nichts probiert - ist nur eine annahme von mir, so wie ich die funktionalität dahinter verstehe)
Bearbeitet von TOM am 24.03.2016, 16:26
|
Smut
takeover & ether
|
key pinning soll eben genau das verhindern.
naja das bedeutet halt auch dass du den verseuchten ******* erkennen musst. In der Regel wird malware noch per http ausgeliefert - wenn es jemand in SSL packt dann sind es meistens schon bessere und die erkennt dann der AV erst recht nicht. also ich bin nicht der Meinung dass SSL interception die Clients besser schützt. TCP reset hast ja auch noch wenn es wirklich jemand per ssl macht.
|
TOM
Super ModeratorOldschool OC.at'ler
|
key pinning soll eben genau das verhindern.
naja das bedeutet halt auch dass du den verseuchten ******* erkennen musst. In der Regel wird malware noch per http ausgeliefert - wenn es jemand in SSL packt dann sind es meistens schon bessere und die erkennt dann der AV erst recht nicht. also ich bin nicht der Meinung dass SSL interception die Clients besser schützt. TCP reset hast ja auch noch wenn es wirklich jemand per ssl macht. wie ich es verstehe soll key-pinning verhidern, dass irgendein offizielles zertifikat von einer trusted source für (z.B.) google.com ausgestellt wird = der client checkt durch das key-pinning "nope, das ist nicht das korrekte zertifikat für google.com" falls du aber vorher schon dem browser ein gültiges zertifikat unterjubelst (z.B. gewohnte proxies die den SSL-traffic aufmachen), trusted er ja dem zertfikat.... und das lautet dann auf z.B "proxy.intern". Der Proxy macht dann eine weitere SSL-connection zu google.com auf und da stimmt das pinned zertfikat ja wieder meines wissens machen es ja inzwischen bereits verbreitete virenscanner so, dass sie ein internes zertifkat am rechner implantieren und somit den SSL-traffic aufmachen.... falls key-pinning so wirkt wie ihr glaubt, wären also nicht nur massig proxy-appliances betroffen, sondern auch antiviren-software.... (my 0,02€ => pest und cholera - aber ich kann verstehen, dass die firmen gezwungen sind möglichst jeden weg abzusichern...)
Bearbeitet von TOM am 24.03.2016, 20:30
|
Redphex
LegendRabbitOfNegativeEuphoria
|
falls key-pinning so wirkt wie ihr glaubt, wären also nicht nur massig proxy-appliances betroffen, sondern auch antiviren-software.... So ist es auch. Und deshalb ist es eigentlich verständlich, daß die Browserhersteller sich nicht trauen, das durchzuziehen - auch wenn's wohl noch nicht weit verbreitet ist. Bzw - bis es mal soweit sein sollte, dass es nicht ignoriert wird, werde ich es in der webserver-config wieder deaktivieren - weil eh' sinnlos.
|
Smut
takeover & ether
|
wie ich es verstehe soll key-pinning verhidern, dass irgendein offizielles zertifikat von einer trusted source für (z.B.) google.com ausgestellt wird = der client checkt durch das key-pinning "nope, das ist nicht das korrekte zertifikat für google.com"
falls du aber vorher schon dem browser ein gültiges zertifikat unterjubelst (z.B. gewohnte proxies die den SSL-traffic aufmachen), trusted er ja dem zertfikat.... und das lautet dann auf z.B "proxy.intern". Der Proxy macht dann eine weitere SSL-connection zu google.com auf und da stimmt das pinned zertfikat ja wieder Und wo ist der Unterschied ob das X509 Zertifikat von dieser internen Root-CA gesigned wurde oder von tuerktrust? - es ist nicht unterscheidbar, da für den Browser rein das vorhanden sein im truststore relevant ist. ein interception Proxy ist ein mitm - genau das willst du mit pinning verhindern! Google selbst erlaubt ja bei ihren Services kein interception - diese Sachen sind halt dann auf der whitelist und werden nicht intercepted. Alle Banking Apps in .at verwenden certificiate pinning in der App. bluecoat und andere haben dafür halt fette whitelists.
Bearbeitet von Smut am 24.03.2016, 22:21
|
TOM
Super ModeratorOldschool OC.at'ler
|
Alle Banking Apps in .at verwenden certificiate pinning in der App hmm...nö Check mal ein paar Online-Bankings mit dem ssllabs.com Test... ich hab auf die schnelle garkeines gefunden, dass HPKP aktiviert hat Im Prinzip bestätigt das hier meine Ansicht: https://bjornjohansen.no/public-key-pinningChrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.
In other words: If someone tricks you into installing their root certificate (like for free WiFi), Chrome won’t validate the certificate with the pinned info. Use FireFox instead.
Bearbeitet von TOM am 25.03.2016, 09:40
|
Anmeldung