hsts deaktivieren

[Alternativende]

Hallo zusammen,
ich musste bei meinem kleinen Server bei der Arbeit den Domainnamen ändern und dementsprechend auch ein neues Zertifikat anlegen. Dies habe ich zwar auch alles getan aber Firefox sperrt nun die Verbindung zum neuen Server mit folgender Meldung:

Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen, dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll. Daher ist es nicht möglich, eine Ausnahme für dieses Zertifikat anzulegen.

uses an invalid security certificate. The certificate is not trusted because it is self-signed. Error code: SEC_ERROR_UNKNOWN_ISSUER

Sicherlich ist das Zertifikat selbst erstellt und auch selbst gesigned, aber normalerweise sollte ich dennoch Zugriff haben.

HIer mal die /etc/apache2/mods-enabled/ssl.conf

Code: Alles auswählen

<IfModule mod_ssl.c>
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 512


AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

SSLPassPhraseDialog  builtin

SSLSessionCache        shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout  300

SSLCipherSuite HIGH:MEDIUM


</IfModule>

Und die default-ssl.conf

Code: Alles auswählen

NameVirtualHost *
<IfModule mod_ssl.c>
	<VirtualHost *:443>
		ServerAdmin webmaster@localhost
		DocumentRoot /var/www/dokuwiki

 ServerName MEINESITE.DE
 ServerAlias www.MEINESITE.de:443
 ServerAlias MEINESITE.de:443
 ServerAdmin MEINE MAIL


 <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>

<Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>



 SSLCertificateKeyFile /etc/apache2/ssl3/apache.key
 SSLCertificateFile /etc/apache2/ssl3/apache.crt

		LogLevel info ssl:warn

		ErrorLog ${APACHE_LOG_DIR}/error.log
		CustomLog ${APACHE_LOG_DIR}/access.log combined


		SSLEngine on

		<FilesMatch "\.(cgi|shtml|phtml|php)$">
				SSLOptions +StdEnvVars
		</FilesMatch>
		<Directory /usr/lib/cgi-bin>
				SSLOptions +StdEnvVars
		</Directory>

		BrowserMatch "MSIE [2-6]" \
				nokeepalive ssl-unclean-shutdown \
				downgrade-1.0 force-response-1.0
		BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

	</VirtualHost>
</IfModule>

Die /etc/httpd.conf ist leer.

In den Logs findet sich nichts, Caches sind alle gelöscht, meherere Browser habe ich probiert.

Hat jemand eine Idee?

[Dimejo]

uses an invalid security certificate. The certificate is not trusted because it is self-signed. Error code: SEC_ERROR_UNKNOWN_ISSUER

Sicherlich ist das Zertifikat selbst erstellt und auch selbst gesigned, aber normalerweise sollte ich dennoch Zugriff haben.

Hast Du die CA in Firefox importiert?

[Alternativende]

Vom Server? Nein.

[Dimejo]

Vom Server? Nein.

Und wie soll Firefox Deinem Zertifikat dann trauen?

[Alternativende]

Normalerweise kann ich es ja hinzufügen wenn das Zertifikat unbekannt ist. Bei dieser Meldung geht das aber nicht.

Übrigens habe ich das auch im Internet Explorer und bei Midori. Keiner zeigt die Website an.

[Dimejo]

Normalerweise kann ich es ja hinzufügen wenn das Zertifikat unbekannt ist. Bei dieser Meldung geht das aber nicht.

Du kannst es in den Einstellungen unter Erweitert => Zertifikate manuell hinzufügen.

Übrigens habe ich das auch im Internet Explorer und bei Midori. Keiner zeigt die Website an.

So soll es bei einem selbst erstellten Zertifikat ja auch sein, oder?

[Alternativende]

Du verstehst glaube ich das Problem nicht. Es ist NICHT die "normale" Meldung. Bitte lies Dir doch mal die Fehlerbeschreibung durch.

Kein Browser macht mir derzeit die Site auf.

[Dimejo]

Du verstehst glaube ich das Problem nicht. Es ist NICHT die "normale" Meldung. Bitte lies Dir doch mal die Fehlerbeschreibung durch.

OK, ich versuche mal zu verstehen:
Du hast eine Seite, die mit einem neuen, selbst erstellten Zertifikat und HSTS gesichert ist. Wenn Du die Seite in Firefox (oder einem anderen Browser) öffnest erhältst Du eine Warnung, dass die Seite nich geöffnet werden kann weil dem Zertifikat nicht getraut wird. Normalerweise kommt unter der Fehlermeldung ein Feld, mit dem man eine Ausnahme für diese Seite erstellen kann. Das ist jetzt aber nicht der Fall. Soweit richtig?

[Alternativende]

Fast. Ich habe eine Site deren Domain sich geändert hat, also neue Domain, neues Zertifikat, selber Server, selber Apache. Und ja, ich kann keine Ausnahme hinzufügen, steht ja auch in der Fehlermeldung.

Nun meckern die Browser rum, Firefox erzählt etwas von HSTS, der IE meint jemand wolle mich austricksen:

Meldung vom IE:

Das Sicherheitszertifikat dieser Website wurde nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt.
Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.

Als ich das Zertifikat mit Openssl erstellt habe, habe ich natürlich den vollen FQDN ohne www. oder https:// bei Common Name eingegeben. Ansonsten hatte ich jetzt nicht viel in der Config vom Apache verändert.

[Dimejo]

Die Fehlermeldungen von Firefox und IE sind ziemlich eindeutig. Die Seite wird nicht geöffnet, weil dem Zertifikat (und dem Aussteller) nicht vertraut wird. Das hat nichts mit OpenSSL, Apache oder dem FQDN zu tun.

[DeletedUserReAsG]

Ich glaube, der Teil stand gar nicht zur Diskussion, sondern »Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen, dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll. Daher ist es nicht möglich, eine Ausnahme für dieses Zertifikat anzulegen.«, wobei offenbar HSTS weder gewollt ist, noch explizit aktiviert wurde und die Frage war, wie man es deaktivieren könne. Für die, die den so extrem langen Eingangsbeitrag nicht durchlesen wollen, steht’s ja auch noch mal im Threadtitel.

… zum Thema weiß ich erstmal auch nix, aber da’s mich durchaus interessiert, wollte ich mal auf die Frage zurücklenken …

[Alternativende]

Danke @niemand, ich weiß nicht wie ich das sonst noch verständlich machen soll.

[Dimejo]

Ich glaube, der Teil stand gar nicht zur Diskussion, sondern »Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen, dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll. Daher ist es nicht möglich, eine Ausnahme für dieses Zertifikat anzulegen.«, wobei offenbar HSTS weder gewollt ist, noch explizit aktiviert wurde und die Frage war, wie man es deaktivieren könne.

Wenn ich ein Zertifikat (oder eine CA) manuell in Firefox importiere ist es das selbe als wenn ich bei der Fehlermeldung auf "Ausnahme" klicke. Das sollte auch bei HSTS funktionieren. Und das Zertifikat muss ich ja sowieso importieren.

Bzgl. HSTS löschen:
Chronik öffnen (Strg + Shift + H), die Webseite auswählen und per Rechtsklick auf "Gesamte Webseite vergessen) gehen.
Dann auf Einstellungen => Erweitert => Netzwerk, und dort die Caches leeren.

[Alternativende]

Das ist ja keine Lösung, selbst wenn das funktionieren sollte. Ich nutze dutzende Computer über die Zeit, dass muss out of the box funktionieren.

Die andere Idee mit dem Vergessen der Website habe ich auch schon ausprobiert, ebenso wie das Löschen diverser Dateien im Firefoxprofilordner etc.. Hat alles nichts gebracht.

Ich werde den Server Morgen früh wohl oder übel neu aufsetzen und dann mal schauen ob das Problem dann beseitigt ist, oder ich beim erzeugen des Zertifikats etwas falsch gemacht habe und es überhaupt nicht am Apache liegt.

[wanne]

Ich werde den Server Morgen früh wohl oder übel neu aufsetzen und dann mal schauen ob das Problem dann beseitigt ist, oder ich beim erzeugen des Zertifikats etwas falsch gemacht habe und es überhaupt nicht am Apache liegt.

Nein. Das hat nichts mit Apache zu tun.
Wenn das Out of the box funktionieren soll, besorg dir ein passendes Zertifikat. Da gibt's die auch kostenlos:
https://letsencrypt.org/
https://www.startssl.com/
Oder auch bei praktisch jedem Hoster. Die wollen dann meistens aber ein bisschen dafür.

Dieses dämliche "Ich kenne das Risiko" (obwohl man es eben nicht tut) gedrückte ohne die die entsprechenden Zertifikate zu überprüfen untergräbt die Sicherheit von TLS mehr oder weniger vollständig.
Dass das in vielen Fällen nicht mehr der bequemste Weg ist hat durchaus Sinn.
HSTS läuft mit der Zeit ab. Typischerweise ist das auf ein Jahr gestellt. Du kannst auch so lange warten.

[DeletedUserReAsG]

Dieses dämliche "Ich kenne das Risiko" (obwohl man es eben nicht tut) gedrückte ohne die die entsprechenden Zertifikate zu überprüfen untergräbt die Sicherheit von TLS mehr oder weniger vollständig.

Dieses Unterstellen ist auch irgendwie daneben. Soll durchaus Leute geben, die den Fingerprint anschauen. Jenseits von „du kannst diesen und jenen und noch einen Workaround nutzen“ würde zumindest mich schon interessieren, wie’s überhaupt zu diesem HSTS kommt, wenn man’s nicht explizit aktiviert hat.

[wanne]

Dieses Unterstellen ist auch irgendwie daneben. Soll durchaus Leute geben, die den Fingerprint anschauen.

Deswegen hatte ich ja geschrieben:

ohne Zertifikate zu überprüfen

Aber mal ganz ehrlich: Wer zu faul ist Zertifikate zu kopieren überprüft auch keine Fingerprints.

würde zumindest mich schon interessieren, wie’s überhaupt zu diesem HSTS kommt

a) Er hat es aktivert. – Und der Sinn von dem Ding ist, dass man es nicht so schnell deaktivieren kann.
b) Der Vorbesitzer der Domain hatte es aktiviert.

[DeletedUserReAsG]

Wo kommt‘s denn nun genau her? Angenommen, der Browser hat ein neues, sauberes Profil und der Server ist explizit nicht dafür konfiguriert, sowas zu verschicken? Der einzige Platz, den ich für den Fall gefunden habe, wäre die von Gugl geführte Liste, und da wird’s für mich bedenklich. Abgesehen davon finde ich überall nur, dass HSTS unverschlüsselte Verbindungen unterbinden soll, nicht, dass es das Nutzen von drittseitig signierten Zertifikaten erzwingen soll. Ich halte das für bedenklich, egal, ob andere das „für eine gute Sache“ halten.

[schorsch_76]

Zu HSTS: HSTS ist ein Header der dem Client immer mitteilt das diese Seite nur HTTPS macht. Es kommt aber auch noch ein max Age Eintrag dazu:

Code: Alles auswählen

Security: max-age=31536000

Das ist etwa ein Jahr.

Alternative a)
Das haben sich ALLE deiner Clients gemerkt. Du solltest ein HTTP Zertifikat von bsp. Startssl oder Letsencrypt nehmen und deine Probleme sollten verschwinden. (Beide CAs haben kostenlose Zertificate)

Alternative b)
Importiere dein eigenes RootCA Zertifikat in den Browser jedes Clients. (Aber das willst du ja nicht)

Oh, und genau das, was du hier machst, soll eben durch HSTS unterbunden werden. Das sagen ja alle deine Meldungen der verschiedenen Browser.


Dein Browser ist in der Zwickmühle:
a) Er soll HTTPS machen (HSTS)
b) dem übermittelten Zertifikat wird nicht getraut.
==> Fehlermeldung.

HSTS addresses this problem[16] by informing the browser that connections to the site should always use TLS/SSL. The HSTS header can be stripped by the attacker if this is the user's first visit. Google Chrome, Mozilla Firefox, Internet Explorer and Microsoft Edge attempt to limit this problem by including a "pre-loaded" list of HSTS sites.[19][20][21] Unfortunately this solution cannot scale to include all websites on the internet. See limitations, below.

Siehe auch [4]

[1] https://en.wikipedia.org/wiki/HTTP_Stri ... t_Security
[2] http://www.heise.de/security/artikel/Se ... 11258.html
[3] https://www.heinlein-support.de/blog/se ... inrichten/
[4] https://blog.mozilla.org/security/2012/ ... ding-hsts/

[Alternativende]

Ich denke nicht das selbst signierte Zertifikate schlechter sind, warum auch? Ich bekäme so jedenfalls definitiv mit wenn sich das Zertifikat "heimlich" ändern würde, bei einem generell von jedem Browser klaglos akzeptiertem Zertifikat ist das nicht der Fall.

Wäre LetsEncrypt bspw. gehackt oder vom Geheimdienst unterwandert könnten die ja wohl ziemlich einfach meine Verbindung belauschen. Bei meinem Zertifikat nicht. Ich bin ja selbst die CA.

Habe aber inzwischen auch die Lösung. Der Provider aktiviert standardmäßig HSTS für die DynDNS Topleveldomain, daher der Fehler.

Edit:
Ich hoffe das war soweit verständlich ausgedrückt . Was ich sagen will ist das wenn ich nun eine SSL-Fehlermeldung bekomme an einem Gerät an dem ich normalerweise das Zertifikat schon akzeptiert habe, dann muss ich stutzig werden. Bei generell akzeptierten ja eher nicht.

[wanne]

Wo kommt‘s denn nun genau her? Angenommen, der Browser hat ein neues, sauberes Profil und der Server ist explizit nicht dafür konfiguriert, sowas zu verschicken? Der einzige Platz, den ich für den Fall gefunden habe, wäre die von Gugl geführte Liste, und da wird’s für mich bedenklich.

Um möglichst großflächigen Schutz zu bieten speichert der Browser absichtlich nicht im Profil sondern Profil übergreifend.
Hat er ein mal in einem beliebigen Profil HSTS empfangen weiß er dass die Seite TLS unterstützt und macht deswegen auch mit keinem andern mehr kein/kaputtes TLS.

Zumindest Chrome hat tatsächlich nochmal von Anfang an eine Liste mit häufigen Domains die Certificate-pinning (was ja so ähnlich ist wie HSTS) machen. Sehe ich jetzt auch nicht ein so großes Problem. Die Liste wird IMMER bei der Installation und bei Updates runter geladen. Ob sie dann benutzt wird verrät er Google nicht. Allerdings werden dadurch erkannte MITM-Attacken an Google gemeldet.
Sehe da kein Missbrauchspotential. Die eingebauten CAs sind da sicher problematischer. Beide Browser haben daneben eine Liste mit bekanntermaßen gestohlenen Zertifikaten, zu denen sie dann keine Verbindungen mehr aufbauen. Da sind aber wirklich nur welche drin, wo der Besitzer die zurückgezogen hat.

Abgesehen davon finde ich überall nur, dass HSTS unverschlüsselte Verbindungen unterbinden soll, nicht, dass es das Nutzen von drittseitig signierten Zertifikaten erzwingen soll.

Zu TLS gehört nuneinmal eine CA. Sonst ist das ganze sinnlos. Ob du die selbst betreibst oder von jemand andrem ist erstmal Wurst. Nur wenn sie Selbst betreibst musst du halt auch selbst darum gucken wie die Zertifikate in dein Betriebssystem kommen. Nur ohne ist TLS halt kaputt und entsprechend tut das nicht.

[DeletedUserReAsG]

Das Missbrauchspotential, das du nicht siehst, ist selbst im korrespondierenden WP-Eintrag aufgezeigt (interessanterweise im Englischen deutlicher als im Deutschen).

Und ich persönlich hätte gerne selbst die Kontrolle über meine Sachen.Wenn ich kein HSTS möchte, hat man mir das auch nicht aufzuzwingen – glücklicherweise hat sich ja rausgestellt, dass es am DNS-Betreiber lag, und den kann man ggf. wechseln.

[wanne]

Das Missbrauchspotential, das du nicht siehst, ist selbst im korrespondierenden WP-Eintrag aufgezeigt

Wo in welchem? Wie schon angemerkt gibts solche Listen für HSTS ja gar nicht.

[wanne]

Ich denke nicht das selbst signierte Zertifikate schlechter sind, warum auch?

Solange Du wirklich deinem Browser deine Certifkate fütterst ist das kein Problem. Nur das Aufbauen der Verbindung ohne Zertifikatscheck ist halt kaputt. Weil da kann halt jeder jeden Schrott reinwerfen. Den sollten sie eigentlich ganz rauswerfen.

Wäre LetsEncrypt bspw. gehackt oder vom Geheimdienst unterwandert könnten die ja wohl ziemlich einfach meine Verbindung belauschen.

Nein. LetsEncrypt signiert meinen öffentlichen Schlüssel nur bekommt aber ganz sicher nie den Privaten zu sehen. Wenn jemand Lets encrypt hackt bekommt er den öffentlichen Teil meines Schlüssels. Den kann er auch direkt von meiner Seite haben. Mit Certificate Pinning braucht er den aber zum belauschen.

Wäre LetsEncrypt bspw. gehackt oder vom Geheimdienst unterwandert könnten die ja wohl ziemlich einfach meine Verbindung belauschen. Bei meinem Zertifikat nicht.

Bullshit. Wenn du kein Certificate-Pinning machst, kann LetsEncrypt selbstverständlich auch für deine Seite ein Zertifikat ausstellen. – Egal ob du bis jetzt eigene Zertifikate hattest oder nicht.

[DeletedUserReAsG]

Wo in welchem? Wie schon angemerkt gibts solche Listen für HSTS ja gar nicht.

Dann sollte mal jemand die ganzen Quellen korrigieren, und bei https://hstspreload.appspot.com/ Bescheid sagen, dass es das ja gar nicht gibt.