Loading...
de

Nutzer-Blogs

Suchergebnisse für: "ssl"
Martin Brunzel Free
Ich spiele schon seit einigen Jahren mit Computern. Dabei setzt man dann auch mal einen SMTP-Server oder einen Webserver auf. Und dabei kommt es dann auch mal vor, dass man eben nicht nur wissen möchte, was der Browser oder der Mailclient sagt ("Connection failed" - Toll...), sondern eben auf Protokollebene wissen möchte, wieso die Verbindung fehlgeschlagen ist.

Ein tolles Tool dafür war immer telnet. "telnet localhost 80 - GET http://localhost/" - und schon hatte man, was der Browser bekam. Direkt, ungeschönt, Byte für Byte. Gut, es ist noch eine alte Version von http (0.9), aber daran stören sich die meisten Server nicht. Und wenn doch, tippe ich halt ein wenig mehr und nehme http/1.1. Wie aber macht man das mit https?

Heute stand ich vor genau diesem Problem: Eine https-Verbindung zu einem Webserver aufbauen. Der naheliegendste Versuch? "telnet localhost 443" - "GET https://localhost/" führte nur dazu, dass der Server meckerte: "400 Bad Request" Über einen SSL-Port nimmt er eben keine nicht-SSL-gesicherten Verbindungen an. Schön, sicher, aber nicht zielführend für mich.

Nach etwas Recherche habe ich dann gnutls gefunden. gnutls gibt es in der Unterform "gnutls-cli", was sehr analog zu telnet funtioniert: "gnutls-cli localhost -p 443" ist das Pendant zum Telnet-Befehl. Die positive Überraschung: Es wird direkt die SSL-Verbindung aufgebaut, und das Zertifikat des Servers auch noch gleich sauber auseinander genommen. "subject 'CN=localhost', issuer 'C=US,O=Let's Encrypt Auhtoriy X1', RSA key 2048 bits, ..." Detailliert werden die Fingerprints, die IDs, alles mögliche aufgeführt. Ich kann mir also sogar anschauen, ob vielleicht ein falsches Zertifikat für die Verbindung verwendet wird. Danach geht's ganz normal weiter, wie beim Telnet. Von der zugrundeliegenden Verschlüsselung merkt man nichts.

Ab heute ist meine Toolbox also um ein weiteres Werkzeug ergänzt: gnutls.

.. und ja, ich habe oben einen Fehler eingebaut: Für localhost wird man kein Zertifikat bekommen, das von Let's Encypt unterschrieben ist. :-) Da es sich hier aber nur um ein Beispiel handelt, sollte das nicht ernsthaft stören.
Martin Brunzel Free
Ich habe mal irgendwo gehört, dass im Schnitt mehr Mails mitgelesen werden, als Postkarten. Wer also vertrauliche Daten verschickt, sollte seine Mails unbedingt verschlüsseln.

Letztlich ist technisch aber das Surfen im Internet auch nicht viel komplizierter mitzulesen. Und in vielen Fällen kann man als User noch einfacher verschlüsseln: Statt http:// einfach ein https:// vor die Adresse in der Adresszeile setzen. Das "s" steht für secure, also verschlüsselt. Das Mitlesen wird dann zumindest deutlich erschwert: Die Webseite identifiziert sich mit einer elektronischen Unterschrift, und als Nutzer kann ich mir anschauen, wer mir die Daten schickt. Wenn das dann auch wirklich die aufgerufene Webseite ist, ist das ja fein für mich.

Ich gebe zu, das bei kleineren Webseiten manchmal einfach mal so "auf gut Glück" zu probieren. Und sehr oft habe ich dann das Problem, dass das nicht unterstützt wird. Der Grund ist auch ganz einfach: So eine elektronische Unterschrift muss natürlich beglaubigt werden. Und diese Beglaubigung dürfen nur wenige Firmen ausstellen. Und die wollen Geld dafür.

... alle? Nein, nicht alle. Seit letztem Jahr versucht sich eine Firma darin, Zertifikate zu verteilen, die kostenfrei sind. Let's encrypt stellt diese Unterschriftsbeglaubigungen einfach jedem aus, der sich die Mühe macht, dort anzufragen. Für Linux haben sie einen Client geschrieben, der von Github heruntergeladen werden kann und einfach so gestartet werden kann. Zusätzlich gibt es einige "Nebenprojekte" wie Web-basierte Anfragen oder Plugins für cPanel.

Ich muss aber auch zugeben, dass ich einige Startschwierigkeiten hatte:

1) Die zu beantragende Webseite läuft nicht lokal, sondern wird gehostet. Damit entfällt schon einiges vom Automatismus, denn letztlich muss ich irgendwie beweisen, dass ich Verfügungsgewalt über die Seite habe.

2) Ich arbeite aktuell hauptsächlich unter Windows.

Gut, Windows soll jetzt mal nicht das Problem sein. Dann kann ich halt nicht den originären Client benutzen, sondern muss mich auf beispielsweise das Webinterface zurückziehen. Aus irgendeinem Grund konnte ich hier aber noch nicht einmal beweisen, dass ich auch Verfügungsgewalt über meinen (persönlichen) Schlüssel habe. Womit auch immer das zusammenhing, ich werde es wohl nie erfahren.

Danach habe ich in meiner minimalen virtuellen Maschine geschaut: Tatsächlich bot mir Gentoo auch den Client von Let's encrypt an. Also schnell installiert. Erwartungsvoll gestartet. Und eine Fehlermeldung von Python geerntet. Toll. Dann eben erstmal nicht.

Wenige Tage später habe ich nochmal geschaut: Tatsächlich gab es eine neue Version. Also diese installiert und gestartet und ... es lief!

Grundsätzlich lief die Bestellung des Zertifikats dann auch reibungslos ab. In meiner Version wenig gut dokumentiert ist der Schalter --manual, den ich unbedingt benötigt habe. Damit sagt man, dass nicht das Programm automatisch den Rechner, auf dem es läuft, für den Verschlüsselungsvorgang verwenden soll, sondern man selbst die Modifikationen am Webserver vornehmen möchte. Im Endeffekt bedeutet das nichts anderes, als dass man in ein bestimmtes Verzeichnis (/.well-known/acme-challenge/) eine Datei mit einem bestimmten Namen und bestimmten Inhalt ablegen muss. Beides sieht ziemlich zufällig aus.

Ebenfalls sollte man sich davor hüten, schon ein Zertifikat installiert zu haben. Das veranlasst Let's encrypt leicht zu Fehlannahmen, bei mir beispielsweise, dass mein Webhoster die Verfügungsmacht über meine Domain hat. (Was ja irgendwie auch wieder passt...)

Ich denke, der erste "Einarbeitungsaufwand" ist vielleicht gegeben, ja. Aber danach geht's wirklich nicht mehr einfacher. Irgendwie fast enttäuschend, wenn dann schon am Bildschirm steht: "Congratulations! Your certificate is ..." Schlussendlich durfte ich noch die Zertifikate meinem Webhoster bekanntgeben, und seitdem kann jeder verschlüsselte Verbindungen ohne Warnung in seinem Webbrowser aufbauen.

Wer sich selbst mal versuchen möchte:
https://letsencrypt.org/

Martin Brunzel Jan 10 '16 · Kommentare: 1 · Stichworte: letsencrypt, verschlüsselung, encryption, ssl, privacy