IT-Blog von Sebastian van de Meer

Schlagwort: Browser (Seite 2 von 3)

Google Browser Chrome wirft SHA1 Zertifikate weg…

Veraltet: SHA-1 in TLS-Zertifikaten ist seit Januar 2017 von allen großen Browsern abgelehnt. Dieser Beitrag ist ein Zeitdokument aus 2014, als Google den Ausstieg ankündigte.

Dass SHA-1 nicht der Brüller ist, wissen wir inzwischen alle. Dass man nicht so lange warten sollte wie bei MD5, bis es nicht nur ein theoretisches, sondern ein echtes Problem gibt, können sich viele denken. Leider bekommt man viele Entscheider nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Softwaremodule müssen getauscht werden, Hardware könnte ersetzt werden müssen. Windows XP wird so zum Beispiel abgehängt.

Googles Ankündigung

Google hat angekündigt, SHA-1 aus Chrome zu entfernen. Nutzt man Zertifikate mit SHA-1-Checksumme, gibt es eine Meldung im Browser: „Diese Seite ist nicht ganz sicher.“ Danach folgt eine deutliche rote Warnung, bis hin zum Punkt, dass solche Zertifikate nicht mehr unterstützt werden. Zeitplan damals: ab ca. 2017. Bei einer durchschnittlichen Gültigkeitsdauer von zwei Jahren für Kaufzertifikate konnte man zum letzten Mal mit gutem Gewissen am 31.12.2014 ein SHA-1-Zertifikat kaufen.

Was mir an Google damals gefiel: Sie haben sanften Druck auf die Entscheider ausgeübt, um mehr Sicherheit ins Internet zu bringen. SHA-1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern. Genau wie RC4 oder MD5. Kein Anwender prüft das von sich aus. Aber wenn die Software anfängt zu meckern, gibt es schnell Bewegung bei den Entscheidern und den „Weiter, weiter, fertigstellen“-Admins. Microsoft und Mozilla hatten sehr ähnliche Pläne.

Die CAs reagieren

Kurz nach der Ankündigung kamen die ersten E-Mails von den großen CAs. Hier die von Symantec:

Wichtiger Servicehinweis

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die
Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1
einzustellen. Das wird voraussichtlich ab Chrome 39 im November 2014
geschehen.

Symantec empfiehlt:
1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer
   Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015
   ablaufen, kostenlos durch Zertifikate mit SHA-2.

Hinweis: Root-Zertifikate mit SHA-1 sind nicht betroffen.

Ihr Support-Team von Symantec Website Security Solutions

Wie es ausgegangen ist

Im Januar 2017 hat Chrome 56 SHA-1-Zertifikate endgültig abgelehnt. Firefox und Edge zogen nach. Heute signiert jede CA mit SHA-256 oder besser. Wer sich für den aktuellen Stand von TLS und Zertifikaten interessiert: Da hat sich seit 2014 einiges getan.

Fragen? Einfach melden.

Google will sicheres Internet.

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Fragen? Einfach melden.

IPv6 und Carrier Grade NAT: Warum nicht der ISP schuld ist

Nach dem IPv6-Kongress 2014 war die Verbreitung mal wieder kurz im Rampenlicht. Nach über 15 Jahren IPv6 war die Umstellung noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert. Es gab ja keine Nachfrage. Bis den ISPs die IPv4-Adressen ausgingen.

Carrier Grade NAT

Wer in Deutschland einen neuen Internetanschluss bei einem Kabelnetzbetreiber bekommt, bekommt oft einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet: Keine eigene öffentliche IPv4-Adresse mehr. Stattdessen eine private Adresse hinter einem zentralen NAT-Router des ISPs. Versteckt wird das hinter Bezeichnungen wie DS-Lite oder DS64-Lite.

Das Port-Problem

Jede TCP-Verbindung verbraucht auf der abgehenden IP-Adresse einen Port. Ports sind 16-Bit-Zahlen, maximal 65.535. Abzüglich der reservierten Ports bleiben rund 64.500 gleichzeitige Verbindungen pro IP. Ein einzelner Benutzer baut schnell 50 und mehr Verbindungen gleichzeitig auf: E-Mail, Messenger, Browser mit parallelen Requests. Dazu kommen Verbindungen die nicht sauber geschlossen werden und bis zum Timeout offen bleiben.

Offene Verbindungen anzeigen:

netstat -tapen

Wenn sich hunderte Kunden eine öffentliche IP teilen, sind die Ports schnell aufgebraucht. Der ISP könnte bestehende Verbindungen nach einer Zeit hart zurücksetzen. Oder die maximale Anzahl gleichzeitiger Verbindungen pro Kunde begrenzen. Beides führt zu Problemen.

Dazu kommt: Viele Webserver und Mailserver begrenzen die Anzahl gleichzeitiger Verbindungen pro IP-Adresse, als Schutz gegen DDoS. Wenn hundert Kunden hinter einer IP sitzen, trifft dieses Limit schnell.

Wer ist schuld?

Ein gutes Beispiel war Sipgate. Der VoIP-Anbieter beschwerte sich öffentlich darüber, dass seine Kunden hinter CGN-Anschlüssen Probleme mit ihren Sipgate-Leitungen hatten. Sipgate schob den schwarzen Peter an Unitymedia und hoffte, dass sich jemand meldet um das Problem gemeinsam zu lösen.

Was dabei unterging: Unitymedia hatte auf eigene Kosten einen Workaround eingerichtet, damit Dienste die es nach Jahren noch nicht geschafft hatten IPv6 zu unterstützen überhaupt noch erreichbar waren. Und dann kommt ein Diensteanbieter und sagt: Dein Workaround funktioniert nicht perfekt mit unserem System, bitte nachbessern.

Facepalm reaction GIF about IPv6 adoption delays

Der Schuldige ist nicht der ISP. Der Schuldige ist der Diensteanbieter, der es nach über 15 Jahren Vorlaufzeit nicht geschafft hat seinen Dienst IPv6-fähig zu machen. Wer Probleme mit seinem Internetanschluss hat die auf CGN zurückzuführen sind: Nicht den ISP anrufen, sondern den Diensteanbieter fragen wann IPv6 kommt.

Fragen? Einfach melden.

dnssec validator Browser Plugin

Veraltet: Das DNSSEC Validator Browser-Plugin wird nicht mehr gepflegt und ist in aktuellen Firefox-/Chrome-Versionen nicht mehr verfügbar. DNSSEC-Validierung sollte auf dem DNS-Resolver stattfinden, nicht im Browser.

Na schau mal einer an… Das Browser Plugin für den DNSSEC Validator kann nun auch DANE / TLSA und er zeigt es angenehm übersichtlich an.

https://www.dnssec-validator.cz/pages/download.html
Ist in jedem Fall noch mal einen Klick wert.

Ein Browserplugin das man probieren sollte….

Kennt ihr eigentlich schon Ghostery? Das ist ein Broswserplugin für zum Beispiel Mozilla Firefox oder Google Chrome…. Es blockt nicht nur bekannte Tracker auf verschiedensten Webseiten, sondern man bekommt auch noch die eine oder andere spannende Information.

Mit einem solchen Plugin wird einem erst recht bewusst, wer da nicht alles hinter einem her ist! Hin und wieder ist es extrem überraschend wer einem da „in den Browser“ schaut.

Achja, nachdem ihr das Plugin installiert habt, solltet ihr in den Einstellungen natürlich seine Arbeit und das Blocken aktivieren.

Fragen? Einfach melden.

Unsichere SSL/TLS-Verschlüsselungen im Firefox deaktivieren

Veraltet: Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr in dieser Form. Moderne Browser deaktivieren unsichere Protokolle und Cipher automatisch. Dieser Beitrag ist veraltet.

Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.

Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!

Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen. Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig.

Ich denke es gibt drei große Punkte an denen man ansetzten kann:

1. Als kleinstes Protokoll TLS1
2. RC4-Stromchiffren komplett deaktivieren
3. Perfect Forwad Secrecy (PFS) vorschreiben

1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt.
2. Wirft die als unsicher geltende RC4 Cipher Suite raus.
3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.

Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.

B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…

1. TLS Version 1.0 als kleinstes unterstütztes Protokoll.
Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.

2. RC4 Cipher Suite deaktivieren.
Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.

3. Perfect Forwad Secrecy (PFS) vorschreiben
Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.

Seine Einstellungen kann man nun am besten prüfen auf: https://www.ssllabs.com/ssltest/viewMyClient.html

Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?


U-P-D-A-T-E

Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.

Oh ja, was man Serverseitig tun könnte findet sich hier…

 

ownCloud News-App

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud, der 2016 als Fork aus ownCloud hervorgegangen ist.

Ich bin ja SOOOO zufrieden, dass kann sich keiner vorstellen. Ich habe einige RSS News Feed abonniert. Natürlich schaffe ich es nicht alles zu lesen. Daher ist es ganz gut einen Feedreader zu haben welcher sich darum kümmert mir neues zu zeigen, altes gut durchsuchbar aufzubereiten und natürlich kenntlich zu machen welche ich bereits gelesen habe.

Dieses Google oder einem anderen „seriösen“ Anbieter zu überlassen… Hm, da habe ich immer Bauchschmerzen. Was geht es diesen Anbieter denn bitte an, was ich wann lese, für wichtig empfinde? Richtig… Nix.

Wenn ich die Daten nur in einer Anwendung auf dem Notebook vorhalte, kann ich sie nur sinnvoll lesen wenn ich am Notebook bin. Sein wir mal ehrlich umschau wo haben wir alle oft Zeit für so etwas? Genau auf dem Klo… Also auf dem Smartphone? Naja, dann habe ich es wieder nur auf dem Smartphone.

Ich nutze schon lange ownCloud um meine Daten, Kalender, Kontakte, Bilder usw. usw. synchron zu halten. Da sollten doch Nachrichten ebenfalls kein Problem sein, oder? Stimmt.

Es gibt ein >>App Framework<< Dieses bietet die News App. Beides lässt sich nach der „Installation“ einfach als ownCloud Admin aktivieren. Natürlich erst das App Framework und dann die News App…

Schon kann man als Benutzer seine Feeds abonnieren. Damit lässt sich alles über den Browser lesen und es gibt eine feine Android App über welche sich alles auf dem SmartPhone lesen lässt.

Die Installation ist denkbar einfach. Ich habe mir direkt einen git clone gezogen und die Daten dann nur verlinkt. Folgende Schritte waren nötig:

$ mkdir /opt/app-framework
$ cd /opt/app-framework
$ git clone https://github.com/owncloud/appframework.git
$ git clone https://github.com/owncloud/news.git
$ ln -s /opt/app-framework/appframework /pfad/zur/owncloud/apps
$ ln -s /opt/app-framework/news /pfad/zur/owncloud/apps
$ chmod -R www-data:www-data /opt/app-framework

Damit die Nachrichten immer schön aktuell sind, muss jemand anstoßen dass sie eingesammelt werden. Dafür nutze ich cron um alle 5 Minuten ein kleines Script zu starten:

*/5 * * * *  /scripte/cloudnews.sh 1>/dev/null 2>/dev/null

Dieses Script tut nichts weiter als über wget die nötige cron.php zu laden und die Ausgabe direkt in den „Müll“ zu werfen.

#!/bin/bash
/usr/bin/wget --no-check-certificate https://cloud.kernel-error.com/cron.php -O /dev/null

Das war es dann schon.

ownCloud und Mozilla-Sync

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud. Mozilla Sync wurde ebenfalls eingestellt — Firefox synchronisiert über Firefox Accounts.

Wem kann man schon trauen? Richtig, niemandem! Man kann also nur das geringste Übel wählen… Im Moment vertraue ich dem Mozilla Browser mehr als dem Google-Browser. Die Browser über verschiedene Geräte und Platformen zu synchronisieren ist eine wunderbare Erleichterung. Nur damit diese Daten immer auf allen Geräte gleichermaßen zur Verfügung stehen müssen sie an einem zentralen Ort vorgehalten werden. Nun habe ich verständlicherweise ein Problem damit diese Daten einfach auf irgendeinen Server, irgendwo in der Welt zu packen. Ich meine… Das sind meine Browserdaten und damit ebenfalls die gespeicherten Kennwörter, meine Leserzeichen, wo ich herumsurfe usw. usw…. OK, die Daten werden dort verschlüsselt abgelegt. Es hinterlässt denn noch ein unangenehmes Gefühl.

Zum Glück gibt es eine Möglichkeit die Daten einfach mit in die ownCloud zu werfen. Einfach als Admin die App „Mozilla Sync“ aktivieren. Schon lässt sich im Firefox die Verbindung zu einem eigenen Server einstellen. Weitere Geräte werden dann so verbunden als wenn man den Mozilla Server nutzen würde.

Firefox Pipelining

Veraltet: HTTP/1.1-Pipelining wurde mit HTTP/2 und HTTP/3 überflüssig. Alle modernen Browser nutzen Multiplexing statt Pipelining. Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr.

Die Pipeliningfunktion vom Firefox ist ein alter Hut, ja. Es ist ein so alter Hut dass man es schon fast wieder vergessen hat. Einmal im Firefox aktiviert schiebt es die Webseiteninhalte „gleichzeitig“ auf den Computer und somit gefühlt etwas schneller. Jetzt sind die Meisten ja irgendwann mal beim Google Chrome hängen geblieben und man muss einfach neidlos anerkennen: Das Teil ist rattenschnell….
Google…. Google ist toll aber wer ist bei Google die Ware? Genau wir! Nun blocken einige Benutzer ganz freudig Cookies im Browser um zumindest ein klein bisschen etwas gegen die Datensammelwut und das einblenden der „personalisierten“ Werbung zu tun. Da kommt Google und baut (ganz schlau) einen Weg ein den Benutzer denn noch zu packen: http://bits.blogs.nytimes.com/2013/09/19/google-is-exploring-an-alternative-to-cookies-for-ad-tracking/

Also doch wieder Firefox oder Midori oder oder?!?!? Japp :-/ Dann aber bitte mit Pipelining, damit es etwas flotter geht. Ach ja, so geht es an:

In der Adresszeile vom Firefox die Seite: about: config aufrufen und die Meldung mit: „Ja ja, ich bin vorsichtig“ abnicken (nein, nicht das Reh). Nun in der Suche einfach folgenden Begriff einwerfen: „pipelining“. Nun Sollten sich in der Anzeige nur noch ca. 11 Einträge befinden. Hier bei den unten stehenden Einträgen durch einen Doppelklick dafür sorgen das aus false ein true wird. Firefox schließen und fertig ist.

network.http.pipelining – true
network.http.proxy.pipelining – true
network.http.pipelining.ssl – true

Wenn man jetzt noch möchte kann man unter: Bearbeiten Einstellungen Erweitert Allgemein den Sanften Bildlauf / smooth scrolling deaktivieren. Viel Erfolg!

gzip

Ja, es sollte Standard sein, es war aber bis heute nicht aktiviert. Jetzt werden meine Seiten erst mit gzip komprimiert und dann an euren Browser ausgeliefert. Euer Browser muss sie dann noch entpacken! Davon solltet ihr aber nichts merken….. Warum das alles? Da gibt es mehrere Gründe:

1. Komprimierte Daten verbrauchen weniger Platz auf der Leitung.

2. Komprimierte Daten sind kleiner uns damit schneller übertragen.

3. Weder der Server noch euer Rechner muss wirklich CPU-Zeit aufbringen um die Daten zu packen/entpacken.

4. Die Webseiten werden bei euch schneller angezeigt.

 

 

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑