Proxy (Verständnis)Frage - TLS/SSL

[guest15032]

Hi zusammen,

ich habe auf meiner OPNsense den transparenten Web Proxy sowie dabei auch das Caching aktiviert. Der transparente Proxy ist nur für HTTP aktiviert. Soweit funktioniert auch alles ganz gut.

In Verbindung mit einigen Sperrlisten (ich habe z.B. die aus dem offiziellen Tutorial genommen) sind mir aber dann folgende Gedanken gekommen:

Den Proxy für TLS/SSL aktivieren, halte ich für einen Bruch der Sicherheit (as es ja auch tatsächlich ist, da ein eigenes Zertifikat genutzt wird).  So lange ich dies also nicht aktiviere, sind auch sämtliche damit verbundenen Konfigurationen sinnlos, z.B. die Firewall Regeln für HTTPS (also das Blocken des Proxy Bypassing, usw.). Außerdem ist es in Folge dessen ja auch so, dass das Caching und die ACLs doch auch nur bei unverschlüsselten Verbindungen zum Tragen kommen.

Da ja inzwischen doch der Großteil aller "wichtigen" Seiten per TLS/SSL ausliefert, frage ich mich einfach ganz stumpf:

Welchen Sinn macht denn eine Konfiguration von ACLs und dem Caching, wenn ich sowieso auf einen transparenten HTTPS Proxy verzichte, aus Sicherheitsgründen? Ok, beim Caching ist das evtl. noch nicht so wichtig, es wird trotzdem ne Menge über HTTP gecached. Aber die ACL machen doch erst dann Sinn, wenn ich auch die Auslieferung über beide Protokolle über den Proxy schicke, oder verstehe ich das hier falsch?

Noch eine Frage an die Allgemeinheit: Wer von Euch hat denn einen HTTPS Proxy aktiv und hat damit ein gutes Gefühl?

Gruß
Chris

[fabian]

1. Es gibt immer noch genug Seiten, die HTTP only sind - leider auch Webshops, bei denen Passwörter und Bestellungen übertragen werden. Die kann man nach wie vor Cachen. Auch Updates kommen oft über HTTP, da deren Integrität über GPG-Signaturen sichergestellt ist (falls du eine übliche Linuxdistribution verwendest. Wenn du mehrere Hosts hast, kann das schon mal was bringen Es sind ja nicht nur Webseiten, die HTTP verwenden, da HTTP heute auch ein "Trägerprotokoll" für andere Protokolle ist.

2. Du musst nicht zwangsweise die HTTPS-Verbindung unterbrechen, wenn du das nicht willst, kannst dann aber nur noch auf Basis von IP-Adressen und Hostnamen filtern (Stichwort SNI). Das Problem dabei ist, dass nur ein Bruchteil der Richtlinie geprüft werden kann und zum Beispiel Dateitypen (zum Beispiel ausführbare Dateien) nicht gesperrt werden können.
Ich breche HTTPS bei mir aus dem Grund auf, weil ich genau wissen will, was da Blödsinn treibt und mir auch den HTTP-Request anschauen können will (Debugging etc.). Man sieht auch welche Android Apps wohin nach Hause telefonieren und kann die Endpunkte gezielt sperren. So ein transparenter Proxy kann die Apps sauber halten (Adblocking) und Datenabfluss verhindern (Anti-Tracking).

3. Ich habe es in bestimmten Netzen im Einsatz, bei denen ich den Herstellern der Anwendungen nicht traue. Im LAN derzeit nicht. Meine Erfahrung zeigt, dass es nicht sonderlich einfach ist, das so einzurichten wie es passt, da es leider immer wieder Probleme gibt. Firefox unter Android verwendet bei mir nicht den Systemzertifikatspeicher -> funktioniert nicht; Google Apps muss man die Server durch lassen, weil die sonst aus irgendeinem Grund nicht funktionieren, ...
Vom Gefühl her würde ich sagen, dass die Sicherheit dadurch nicht gemindert wird, sofern keiner mein Root-Zertifikat klaut und damit selbst einen MitM platziert. Dafür kann ich meinen ganzen Traffic am Proxy/ICAP Server analysieren und weiß, was für Daten übertragen werden.
Das könnte insbesondere bei werbefinanzierten Apps zu interessanten Erkenntnissen  führen.

[Oxygen61]

Hey hey,

Im Grunde "brichst" du deine Sicherheit nicht, solange wie niemand an dein Root-Zertifikat kommt, welches du für den HTTPS-Proxy verwendest. Vielleicht noch als kleine Ergänzung um dir entweder die Angst vor dem HTTPS Proxy zu nehmen oder deine Paranoia gegenüber Antiviren Software anzutreiben:
SSL Interception wird bei fast jedem Antiviren Hersteller per Default bereits angewendet um HTTPS Traffic zu überprüfen. Dann schalte ich doch lieber den Software-Antivirus aus und nutze meine selbst gebastelte ICAP und HTTPS Proxy Lösung als Ersatz oder?

Schöne Grüße
Oxy

[monstermania]

Moin,
das Thema SSL-Interception sehe ich generell als sehr kritisch an.
1. Ist so etwas für ein reines Sperren von Webseiten oder Kategorien gar nicht nötig (auch mit der OPNsense).
Wenn ich z.B. Facebook oder Twitter nicht erlauben möchte, kann ich das Sperren ohne den Traffic aufzubrechen und ggf. zu analysieren.
2. Informiert Ihr alle Nutzer Eures Netzwerks darüber, dass Ihr Sie ggf. belauscht!? Klar, wenn es nur ein privates Netz ist, mögt nur Ihr selbst davon betroffen sein. Aber schnell kann so etwas ja kritisch werden, wenn man z.B. ein Gästenetz anbietet. Ein guter Artikel dazu -> https://kowabit.de/der-firewall/
3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.

Für uns im Unternehmen hat das schlussendlich dazu geführt, dass wir SSL-Interception nach kurzer Testphase wieder deaktiviert haben. Dazu kam dann auch, dass diverse Anwendungen sehr wohl bemerken, dass die SSL-Verschlüsselung gebrochen wurde und entsprechend nicht mehr funktionieren (So sollte es auch sein!!!). Das Pflegen der Außnahmelisten war entsprechend aufwändig und führt das Ganze dann eh wieder ins Absurde.

Privat bzw. zu Hause ist das für mich eh kein Thema! Da weiß ich ja auf welchen Webseiten ich mich herumtreibe bzw. welches Apps ich nutze.

Gruß
Dirk

[guest15032]

Guten Morgen,

@monstermania hat mir einiges schon vorweg genommen.

Es gibt immer noch genug Seiten, die HTTP only sind -

Ja, da hast Du völlig recht. Insofern sehe ich das Caching da auch nicht als unnütz an.

da HTTP heute auch ein "Trägerprotokoll" für andere Protokolle ist.

Ja, auch hier Zustimmung.

Ich breche HTTPS bei mir aus dem Grund auf, weil ich genau wissen will, was da Blödsinn treibt und mir auch den HTTP-Request anschauen können will (Debugging etc.). Man sieht auch welche Android Apps wohin nach Hause telefonieren und kann die Endpunkte gezielt sperren. So ein transparenter Proxy kann die Apps sauber halten (Adblocking) und Datenabfluss verhindern (Anti-Tracking).

Das ist aus reiner Informationssicht nachvollziehbar. Ich hatte zu diesem Grund vor einiger Zeit mal mit einem Proxy auf meinem Rechner rumgespielt, noch bevor ich die Firewall angeschafft hatte. Ich hatte den Datenverkehr über den Proxy geleitet um zu sehen, was Whatsapp und Co. da alles durchreichen. Allerdings ist das hier eben der Punkt: Einen Proxy temporär zu nutzen, um solche Verbindungen mal zu untersuchen, mache ich gerne. TLS/SSL Proxy dauerhaft auf der Firewall aktivieren, hinterlässt mir kein gutes Gefühl.

Vom Gefühl her würde ich sagen, dass die Sicherheit dadurch nicht gemindert wird, sofern keiner mein Root-Zertifikat klaut und damit selbst einen MitM platziert. Dafür kann ich meinen ganzen Traffic am Proxy/ICAP Server analysieren und weiß, was für Daten übertragen werden.

Auch das kann ich zwar nachvollziehen aber - für mich persönlich - nicht so ganz legitimieren. Ich sehe hier eben den Bruch im Sicherheitsprotokoll. Ganz unabhängig davon, dass ich ebenfalls festgestellt habe, dass diverse Software nicht mehr korrekt funktioniert (bei mir machte z.B. Chrome Probleme).

Im Grunde "brichst" du deine Sicherheit nicht, solange wie niemand an dein Root-Zertifikat kommt, welches du für den HTTPS-Proxy verwendest. Vielleicht noch als kleine Ergänzung um dir entweder die Angst vor dem HTTPS Proxy zu nehmen oder deine Paranoia gegenüber Antiviren Software anzutreiben:
SSL Interception wird bei fast jedem Antiviren Hersteller per Default bereits angewendet um HTTPS Traffic zu überprüfen. Dann schalte ich doch lieber den Software-Antivirus aus und nutze meine selbst gebastelte ICAP und HTTPS Proxy Lösung als Ersatz oder?

Genau das ist es, was mir im Kopf umher geht, und was monstermania auch gepostet hat: Diese Interception ist, laut diverser Fachleute (die ich für urteilsfähig halte) absolut falsch. Natürlich ist es klar, dass eine Untersuchung des Datenverkehrs nicht wirklich anders zu bewerkstelligen ist, vor allem wenn man auf ein Sicherheitsprodukt vertrauen möchte. Aber diese gängige Praxis reißt eben riesige Löcher in genau die Stelle, in die ich ja vertrauen möchte und sollte!

ich nutze seit Jahren keine Antiviren Software mehr (zumal mein OS das zum Großeil auch überflüssig macht) und verlasse mich auf meinen Sachverstand und meine Intuition. Kritische Dinge, wenn sie denn mal vorkommen, mache ich dann in einer VM, usw. Was ich in den letzten Wochen gelesen habe zu genau diesen Themen (Antivirus und TLS/SSL) macht mich nicht nur hellhörig sondern bestätigt auch mein Gefühl, das ich schon zuvor hatte.

1. Ist so etwas für ein reines Sperren von Webseiten oder Kategorien gar nicht nötig (auch mit der OPNsense).
Wenn ich z.B. Facebook oder Twitter nicht erlauben möchte, kann ich das Sperren ohne den Traffic aufzubrechen und ggf. zu analysieren.

Wie genau ist das gemeint? Worauf genau bezieht sich das (technisch)?

2. Informiert Ihr alle Nutzer Eures Netzwerks darüber, dass Ihr Sie ggf. belauscht!? Klar, wenn es nur ein privates Netz ist, mögt nur Ihr selbst davon betroffen sein. Aber schnell kann so etwas ja kritisch werden, wenn man z.B. ein Gästenetz anbietet. Ein guter Artikel dazu -> https://kowabit.de/der-firewall/

Den Artikel habe ich auch vor Augen und noch einige andere. Selbst wenn es  nur das eigene Netz zu Hause ist, leidet hier ja eben schon die Funktionaliät diverser Software. Hab da z.B. auch diverse Zertifikatsfehler gesehen, usw.

3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.

Exakt. ich denke auch, dass es definitiv diskutabel ist. Aber runtergebrochen ist es, zumindest hier im Fokus auf AV Hersteller, doch gut nachvollziehbar, dass die Hersteller ihre Produkte den Bach runterfließen sehen und natürlich jede Kritik ablehnen. Dabei sind die technischen Punkte, also die tatsächlich problematischen bis kritischen Fehler in den TLS/SSL Interceptions, dermaßen gewichtig.


Ich stehe dem insgesamt sehr kritisch gegenüber und bin aktuell der Meinung, dass ich der Sicherheit in das Protokoll Vorzug gebe vor der "Annehmlichkeit", dass ich auch verschlüsselten Datenverkehr selbst unter Kontrolle habe.  ich empfinde es irgendwie als  absurd, die Verschlüsselung aufzuheben, um selbst dann doch wieder zu verschlüsseln, weil man den Datenverkehr an genau dieser Stelle untersuchen möchte. Aus Sicht der Neugier, um zu wissen, was da alles passiert, verstehe ich es vollkommen. Ein kleiner Teufelskreis im Moment...

[fabian]

Es ist durchaus legitim, TLS-Unterbrechung abzulehnen. Nur hat man genau dann das Problem, dass man damit wieder die Kontrolle über den Content verliert. Filterung auf Basis von Hostnamen ist ja trotzderm möglich. Das Problem ist dann aber, wenn es granular werden muss.

Nur so als Beispiel: Wenn eine Webseite example.com Werbung von example.net nachladen will und dazu erstmal https://example.net/check.js
ladt und die Webseite damit damit nicht mehr geht, man aber https://example.net/ads.js sperren will, geht das mit hostbasierten Filtern nicht mehr, da diese Information bereits verschlüsselt übertragen wird.

Auch ein über ICAP angebundener  Virenscanner würde nicht funktionieren, wenn TLS nicht terminiert wurde.


Vielleicht hilft aber das hier: In dem Fall hat man zwei TLS-Verbindungen. Wenn beide sicher sind, ist alles OK. Wenn der Server ein ungültiges Sicherheitszertifikat verwenden würde, würde der Proxy in OPNsense die Verbindung verweigern (der Client bekommt eine Fehlerseite angezeigt). Die Verbindung nach außen kann sogar sicherer sein, als die innen, wenn zum Beispiel bis zum Proxy TLS 1.0 gesprochen wird, und der Proxy nach außen dann eine mit TLS 1.2 gesicherte Verbindung aufbaut.

Was den Einsatz in Betrieben angeht: Hier muss klar gesagt werden, dass es hier durchaus zu Problemen mit gewissen Gesetzen in manchen Ländern geben kann (unter Auflagen erlaubt, generell verboten). Hier sollte aber ein Jurist zur Verfügung stehen, der um diese Fragen kümmern kann, damit diese Fragen geklärt sind.

Ich mache es bei mir zu Hause. Es sollten also nur meine Daten betroffen sein

[Oxygen61]

Was den Einsatz in Betrieben angeht: Hier muss klar gesagt werden, dass es hier durchaus zu Problemen mit gewissen Gesetzen in manchen Ländern geben kann (unter Auflagen erlaubt, generell verboten). Hier sollte aber ein Jurist zur Verfügung stehen, der um diese Fragen kümmern kann, damit diese Fragen geklärt sind.

Ich mache es bei mir zu Hause. Es sollten also nur meine Daten betroffen sein

Eben. Und genau hier muss man unterscheiden. Bei mir auf Arbeit ist SSL-Interception NICHT erlaubt worden (juristisch). Zuhause frage ich meine Mitbewohner (Familie, Freunde, WG-Kumpels) ggf. schriftlich um Erlaubnis und kümmer mich dann halt darum den Traffic sauber zu halten. Man darf hier nicht vergessen, dass man selber ja nicht die NSA spielt oder einen "auf Google macht". Man analysiert ja nicht um herauszufinden, wie lustig der WG-Kumpel wieder sein Leben im Internet verbringt.

Zuhause läuft ganz klar entweder gar keine Antiviren Software (Ersatz durch ICAP Lösung) oder man schaltet HTTPS Untersuchung zu mindestens aus in der Antiviren Software.

Weiterhin wird SSL doch "nur" im internen Netz gebrochen eben genau für z.B. ICAP. Es ist ja nicht so, dass nach der OPNsense nach außen dann unverschlüsselt kommuniziert wird. (Oder irre ich mich?? )

Genau das ist es, was mir im Kopf umher geht, und was monstermania auch gepostet hat: Diese Interception ist, laut diverser Fachleute (die ich für urteilsfähig halte) absolut falsch.

3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.

Das ist ja alles ganz richtig, jedoch ist man doch selber kein AV Hersteller. Die Kritik gegenüber den Antiviren Herstellern ist doch folgender: Die AV Vertreiber können deinen HTTPs Traffic mitlesen und verstehen, weil sie MITM spielen (meist ohne Wissen des Endkundens) jedoch eigentlich selbst völlig unsichere Software dafür bereitstellen, denen man für solch heikle Aktionen gar nicht genug vertrauen darf.
Nun vertrau ich doch mir selber viel mehr als irgend einem AV Hersteller.
Da brech ich doch lieber selber das Protokoll und habe unter Kontrolle was passiert, anstatt dem AV Hersteller das ohne mein Wissen zu überlassen?

Auch ein über ICAP angebundener  Virenscanner würde nicht funktionieren, wenn TLS nicht terminiert wurde.

@fabian aber HTTP Traffic kann doch immer noch untersucht werden oder? HTTPS Traffic logischer Weise nicht, aber wenn man sich dafür entscheidet SSL zu vertrauen, will man das ja auch gar nicht.

Also als Beispiel: Ich nutze einen HTTP Proxy auf der OPNsense und nutze zusätzlich einen ICAP Server...
Wie wäre da die Vorgehensweise bei ICAP? HTTPS traffic ignorieren und nur HTTP Traffic untersuchen oder gibt es dort nur "entweder" "oder"?? Würde ICAP also in diesem Falle gar nicht funktionieren und Fehler ausspucken oder kann man ICAP so einrichten, dass HTTPS Traffic ignoriert wird?

[JeGr]

Ein kurzer Gedankenanstoß noch zu SSL Termination auf "der anderen Seite" (also beim Client):

Wessen Proxy ist so eingestellt, dass er falsche, kaputte, unbekannte, unsaubere Zertifikate oder nicht vollständige Zertifikatsketten ablehnt? Wie bekomme ich als Client hinter dem Proxy mit, dass meine Verbindung zu "vielleicht-eine-bank.de" ein unsauberes Zertifikat retour liefert - da der Proxy die Verbindung öffnet (und ggf. das Zert annimmt, damit nicht so viele Fehler zum Client durchschlagen) und neu verschlüsselt, sieht für mich alles toll aus.

-> man nimmt dem Benutzer bzw. dessen Browser und sonstigen Tools durch re-encryption die Möglichkeit, selbst angemessen auf Probleme zu reagieren!

Anderes Beispiel: Zertifikatskette gebrochen oder ggf. nicht mehr sauber, Zertifikat als zurückgezogen gemeldet etc. Ist der Proxy genauso aktuell wie der Browser der sich automatisch updated? Hoffentlich, denn mein Browser lehnt z.B. Zertifikate von unsauberen CAs oder fehlerhaften Intermediates ab. Durch Re-encrypt sehe ich da nur meine 20 Jahre Eigenbau CA die erlaubt wird...

Da bin ich ebenso kritisch!

Grüße

[fabian]

Also als Beispiel: Ich nutze einen HTTP Proxy auf der OPNsense und nutze zusätzlich einen ICAP Server...
Wie wäre da die Vorgehensweise bei ICAP? HTTPS traffic ignorieren und nur HTTP Traffic untersuchen oder gibt es dort nur "entweder" "oder"?? Würde ICAP also in diesem Falle gar nicht funktionieren und Fehler ausspucken oder kann man ICAP so einrichten, dass HTTPS Traffic ignoriert wird?

Für die Konfiguration von ICAP ist es unerheblich, ob TLS unterbrochen wird oder nicht. Wenn der Traffic lesbares HTTP ist (darunter fällt auch aufgebrochenes HTTPS), wird wird es verarbeitet.

Wessen Proxy ist so eingestellt, dass er falsche, kaputte, unbekannte, unsaubere Zertifikate oder nicht vollständige Zertifikatsketten ablehnt? Wie bekomme ich als Client hinter dem Proxy mit, dass meine Verbindung zu "vielleicht-eine-bank.de" ein unsauberes Zertifikat retour liefert - da der Proxy die Verbindung öffnet (und ggf. das Zert annimmt, damit nicht so viele Fehler zum Client durchschlagen) und neu verschlüsselt, sieht für mich alles toll aus.

Squid (Proxy in OPNsense Blockiert in dem Fall den Zugriff komplett)

Anderes Beispiel: Zertifikatskette gebrochen oder ggf. nicht mehr sauber, Zertifikat als zurückgezogen gemeldet etc. Ist der Proxy genauso aktuell wie der Browser der sich automatisch updated?

Das hat nix mit Browser-Updates zu tun. Für das gibt es OCSP und CRLs.

Hoffentlich, denn mein Browser lehnt z.B. Zertifikate von unsauberen CAs oder fehlerhaften Intermediates ab.

Das kommt darauf an, welche Zertifikate im Trust-Store sind. Wenn ein intermediate-Zertifikat probleme macht, muss es von der darüberliegenden CA per CRL oder OCSP gesperrt werden. Damit hat sich das erledigt.
Sollte das nicht passieren, kann es sein, dass es die ausstellende CA bald nicht mehr gibt, da ihr dann recht schnell von Browser und Betriebssystemherstellern entzogen werden und sie damit keinen Cent mehr wert ist. Daher werden die sich hüten, falsche Zertifkate auszustellen und bei Bedarf nicht zu sperren. Ein Beispiel gibts hier: https://de.wikipedia.org/wiki/DigiNotar

[JeGr]

Daher werden die sich hüten, falsche Zertifkate auszustellen und bei Bedarf nicht zu sperren. Ein Beispiel gibts hier:

Zu dem Satz sage ich nur (wiederholt): Symantec (und ihre unheilige Ehe mit Blue Coat). Wie oft wurden jetzt schon angebliche Demo, Test und sonstige Zerts von gültigen! CAs von Symantec unterschrieben die für Google und Co ausgestellt waren und absolut gültig waren? Zu Tests mit Laufzeiten von 3 Jahren und mehr? *hust hust*

Ich sehe das Zertifikat nicht mehr und habe also keine Chance sowas zu bemerken. Genauso wie HPKP und HSTS unterwandert werden.

[fabian]

Zu dem Satz sage ich nur (wiederholt): Symantec (und ihre unheilige Ehe mit Blue Coat). Wie oft wurden jetzt schon angebliche Demo, Test und sonstige Zerts von gültigen! CAs von Symantec unterschrieben die für Google und Co ausgestellt waren und absolut gültig waren? Zu Tests mit Laufzeiten von 3 Jahren und mehr? *hust hust*

Ich sehe das Zertifikat nicht mehr und habe also keine Chance sowas zu bemerken. Genauso wie HPKP und HSTS unterwandert werden.

Als ich das gelesen habe, habe ich dieses Zertifikat auf eine Blacklist gesetzt. Es sei dir dennoch freigestellt, Symantec aus dem Keystore zu verbannen.

In dem Fall hast du sogar einen Vorteil: machst du es auf dem Proxy, wird der effekt im ganzen Netzwerk sichtbar (keiner kann eine Webseite besuchen, deren Zertifikat von Symantec unterschrieben wurde).

[JeGr]

Das hat mit freigestellt o.ä. einfach nichts zu tun. Du möchtest die Lösung, sei dir gegönnt. Ich mag sie nicht, denn man sieht so etwas schlicht nicht mehr. Bzw. einer muss sich dauerhaft damit beschäftigen, das kontrollieren und umsetzen, damit es für alle sauber funktioniert. Macht er das nicht, haben alle gleichzeitig ein Problem weil sie durch den Proxy immer heile Welt vorgegaukelt bekommen. Und genau aus dem Grund sind die Experten gegen SSL Interception auf Client Seite, weil immer Dinge verschleiert werden, die damit gar nicht erst beim Client ankommen, sondern vorher schon umgebaut werden. Man kann sich also nicht darauf verlassen.

Das kann nett sein, wenn man es zur Kontrolle nutzt (dannn hat man aber eh noch diverse Bestimmungen am Hals zwecks Datenschutz) oder zur Sicherung/Sicherheit. Nur wessen Sicherheit wird denn erhöht? Meine Clients bzw. Nutzer sind sicherer, wenn sie selbst aufgeklärt sind was diverse Szenarien anrichten und was das bedeutet, anstatt ihnen beim Surfen einfach vorzugaukeln alles wäre schick. Wenn ich bei jeder Seite einfach immer meine Dummy-CA sehe, wie soll man da jemand beibringen mal ein Zertifikat mit Argwohn zu beäugen, dass vielleicht nur vorgibt korrekt zu sein bzw. das einfach nicht passt (Stichwort Phishing). Das Problem bei sowas ist, dass Leute davon ausgehen dass das dann immer so ist und auch so sorglos agieren, wenn sie nicht mehr hinter dieser Proxy-"geschützten" Lösung sind. Und das halte ich persönlich für grenzwertig und eher schutzsenkend als -fördernd.

But I agree to disagree on this topic

[fabian]

Phishing-Seiten haben ein gültiges Sicherheitszertifikat, weil sie eine eigene Domain haben und sich diese auch überprüfen lassen können. Da hilft das also genau gar nichts.

User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...

Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.

Aber das ist natürlich ein ganz anderes Thema.

[JeGr]

Phishing-Seiten haben ein gültiges Sicherheitszertifikat, weil sie eine eigene Domain haben und sich diese auch überprüfen lassen können. Da hilft das also genau gar nichts.

Doch, weil ich das Zertifikat _selbst_ prüfen kann. Bank: EV Zertifikat mit grünem Balken. Phisher: meist / immer irgendein Guffel-DV Zertifikat. Kein grüner Balken bei der Bank? Oh wait!
-> funktioniert nicht mehr, ich kann nicht mehr in das Zert reinsehen für wen es ausgestellt wurde. Und bei allem größer Class 2 steht da nicht nur "domain.tld" sondern eine komplette Anschrift die validiert sein muss.

User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...

Nennt sich Erziehung, Aufklärung und Training. Wenn jemand bei einer Bank oder anderen Seite, bei der EV bspw. Pflicht ist keinen grünen Balken sieht, werden sie mißtrauisch. Sowas kann man lernen oder informierend weiter geben.

Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.

Wird meist eh nur auf Windows Systemen funktionieren und dort ist in den meisten Umgebungen ein halbwegs ordentlicher Virenschutz (leider) immer noch Pflicht. Und ich bezweifle mal ganz stark, dass ein eingeschleifter ClamAV mit seiner recht schwachen Scan-Leistung da besser sein sollte als ein richtiger Client der mehrfach am Tag mit Signaturen versorgt wird. Und hier rede ich von einem reinen Virenscanner. Keinem Internet Security Suite Mistding, das sich selbst wieder wie eine Krake in Verbindungen eingräbt wo sie nichts zu suchen hat (Ja, ich schaue zu dir, Kaspersky, Symantec und Co.).

Bleibt jedoch der Punkt, dass der Proxy an der Stelle meines Erachtens mehr Ärger bringt als er potentiell beseitigen soll plus Schutzmechanismen bzw. Prüfmechanismen aushebelt, die anders besser funktionieren. Wie sich ein Proxy bspw. auf HPKP und HSTS auswirkt, hast du bspw. nicht beachtet in deinen Ausführungen. Diese werden - zumindest laut meinem letzten Stand - nicht weitergereicht. Ein Client bekommt also bspw. nicht mit, dass eine Verbindung auf SSL gefordert wird und HTTP gar nicht mehr erlaubt ist. Und sendet somit evtl. Daten versehentlich im Klartext.

Aber wie schon gesagt, ich sehe das anders und lege das nur dar, warum. Ich zwinge niemand meine Meinung auf. TLS ist problematisch genug ordentlich durch-/umzusetzen (schon auf Hostingseite), sich dann noch mit Proxies dazwischen in den Fuß zu schießen halte ich eben für kontraproduktiv. Und wir als Hoster haben schon oft genug gehört "dass die Seite auf dem Server nicht funktioniert", was dann eben doch wieder ein Proxy Problem in der eigenen Hoheit war. Insofern kenne ich beide Seite zu genüge

[Oxygen61]

User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...

Nennt sich Erziehung, Aufklärung und Training.

Da kann ich aus meiner Perspektive nur ganz pessimistisch sagen: Es ist zu spät für Aufklärung und Training.
Nicht unbedingt, weil die Leute nicht wissen wollen worauf sie achten sollen, sondern ganz einfach weil sie nicht länger verstehen wie das Gerät funktioniert was vor ihnen sitzt. Es kommt logischer Weise immer auf den Menschen an, dem man etwas erzählt, aber wenn man den.. naja "etwas unbeholfenen" 90% Social Media nutzenden Mob als Beispiel betrachtet dann ist schlicht und ergreifend "Training" verschwendete Zeit.
Menschen werden nämlich Träge wenn man ihnen jeden Tag sagt, worauf sie zu achten haben und worauf nicht.
Praktisches Beispiel hierbei: Freunde und Familie.
An vielen Ecken hört man auch "Taskmanager? Ich will die Kiste nutzen und nicht auseinander nehmen." oder "Netzwerk funktioniert doch mit dem Gerät von der xyz-Firma. Gegen die NSA können wir eh nichts machen also brauch ich mich auch nicht um Datenschutz oder Sicherheit kümmern".....
MAC und iOS boomen nicht ohne Grund. Und das bestimmt nicht, weil sie besonders konfigurierfreudig sind. 

Locky ist seit 2015 bekannt und die Art der phishing Mails haben sich auch bei den anderen Trojaner Abkömmlingen nicht geändert. Trotzdem versagt der normale Nutzer, wenn durch frühere Hacks halt eine Email zusammen geschustert wird mit personalisierten Daten die tatsächlich stimmen.
Da kann man noch so viel trainieren und erzählen. Da ist Hopfen und Malz halt verloren.
Und jetzt mal ganz ehrlich, frag doch mal deinen Nachbarn was "HTTPS" bedeutet?
Da erkennt niemand irgendwas, auch wenn das Bank Logo geändert wird. "Das war dann halt so gewollt von der Bank".

Wird meist eh nur auf Windows Systemen funktionieren und dort ist in den meisten Umgebungen ein halbwegs ordentlicher Virenschutz (leider) immer noch Pflicht. Und ich bezweifle mal ganz stark, dass ein eingeschleifter ClamAV mit seiner recht schwachen Scan-Leistung da besser sein sollte als ein richtiger Client der mehrfach am Tag mit Signaturen versorgt wird.

Naja die Kombi macht es doch. Das steht sogar in der OPNsense Doku so drinne. Hehe  
Siehe:
The Anti Virus Engine can protect you against malicious websites and infected file downloads, it does not protect the local clients. Therefore it is always a good idea to install a client based solution as well to protect against other forms of infection such as through emails or usb stick.

EDIT: Mich hier aber bitte nicht falsch verstehen. Ich bin auf jeden Fall gegen das Aufbrechen von SSL im Betrieb oder in der Firma, jedoch finde ich die Idee für Zuhause "ganz interessant", würde mir den Stress aber nicht machen wollen.