| Info | IT-News | Tech | OT |

Erledigt Wechsel auf https, dadurch eventuell Logouts

Status
Für weitere Antworten geschlossen.
Opik

Opik

Team (Technik)
Mitarbeiter
Hi,
ich werde nach und nach auf https only umstellen.
Erster Schritt ist erst mal, dass alle dynamisch erzeugten Boardlinks auf https zeigen.

Links in Posts können dadurch aber nach wie vor http (ohne s) sein.

Je nach Browser werden die Cookies für http und https verschieden gehandelt, wodurch ihr
"ausgeloggt" werdet, jedenfalls wird es euch so vorkommen.

Im nächsten Schritt (noch dieses WE) leite ich alle http anfragen nach https um,
dann kann das auch nicht mehr passieren.

Gruß Opik
 
SkAvEnGeR

SkAvEnGeR

Master of Tools
Gibt es auch irgendeine Möglichkeit, das Board ohne https zu benutzen?

Irgendwie hat meine WLAN-Verbindung manchmal Probleme mit https. Standard http klappt hingegen immer einwandfrei.
 
SkAvEnGeR

SkAvEnGeR

Master of Tools
Also Wie oder Warum kann ich dir nicht sagen.
Ich weiss nur, das https-Verbindungen wesentlich langsamer sind, als normale.
Grund könnte eventuell das niedrige WLAN-Signal von nur 42% sein. (großer Abstand zum Router)
 
DrSnuggles

DrSnuggles

Bekanntes Mitglied
@SkAvEnGeR:

Ich würde an deiner Stelle dem Problem auf den Grund gehen und nicht die Boardsicherheit für alle herabsetzen ...
 
Opik

Opik

Team (Technik)
Mitarbeiter
Doch, weil wir "https only" abschalten müssten. Und das wäre sicherheitstechnisch nicht wünschenswert.
 
chaospir8

chaospir8

★★★★★-Oldie
Die Antwort auf seine Frage ist somit "Nein, gibt es nicht, weil wir "https only" abschalten müssten. Und das wäre sicherheitstechnisch nicht wünschenswert."
Und somit setzt der (mehr oder weniger liebe ;)) skavenger mit seiner Frage weiterhin für keinen von uns die Sicherheit herab.
Er hat ja nur etwas gefragt und schon wird einem was unterstellt ... :|
 
SkAvEnGeR

SkAvEnGeR

Master of Tools
Danke das du für mich "in die Bresche Springst" chaospir8. :yo

Ich habe ein Problem und dazu eine Frage gestellt.
Natürlich möchte ich nicht, das die Sicherheit für alle den Bach runter geht.
Wenn es keine Möglichkeit für einzelne Nutzer gibt, https zu umgehen, dann muss ich wohl damit leben.
Eine kurze Antwort, das es keine Möglichkeit gibt, häte mir völlig gereicht.

Danke an alle beteiligten!
 
Opik

Opik

Team (Technik)
Mitarbeiter
Was fehlt denn an Cipher? Ich hab die nginx defaults genommen und mir bekannte unsichere dann gesperrt. Eventuell fehlt dann was, wenn es nicht dabei war.
 
SpRuZ

SpRuZ

Beginner
Opik, ich bin kein Fachmann und kann nichts beitragen, aber schau mal bitte hier im Board.
Cipher Suites Supported by Your Browser (ordered by preference):
(c0,2b) ECDHE-ECDSA-AES128-GCM-SHA256 128 Bit Key exchange: ECDH, encryption: AES, MAC: SHA256.
(c0,2f) ECDHE-RSA-AES128-GCM-SHA256 128 Bit Key exchange: ECDH, encryption: AES, MAC: SHA256.
(c0,0a) ECDHE-ECDSA-AES256-SHA 256 Bit Key exchange: ECDH, encryption: AES, MAC: SHA1.
(c0,09) ECDHE-ECDSA-AES128-SHA 128 Bit Key exchange: ECDH, encryption: AES, MAC: SHA1.
(c0,13) ECDHE-RSA-AES128-SHA 128 Bit Key exchange: ECDH, encryption: AES, MAC: SHA1.
(c0,14) ECDHE-RSA-AES256-SHA 256 Bit Key exchange: ECDH, encryption: AES, MAC: SHA1.
(00,33) DHE-RSA-AES128-SHA 128 Bit Key exchange: DH, encryption: AES, MAC: SHA1.
(00,32) DHE-DSS-AES128-SHA 128 Bit Key exchange: DH, encryption: AES, MAC: SHA1.
(00,39) DHE-RSA-AES256-SHA 256 Bit Key exchange: DH, encryption: AES, MAC: SHA1.
(00,2f) RSA-AES128-SHA 128 Bit Key exchange: RSA, encryption: AES, MAC: SHA1.
(00,35) RSA-AES256-SHA 256 Bit Key exchange: RSA, encryption: AES, MAC: SHA1.
(00,0a) RSA-3DES-EDE-SHA 168 Bit Key exchange: RSA, encryption: 3DES, MAC: SHA1.
Ich habe RC4 für den Firefox deaktiviert und wollte nur noch Verbindungen ab TLS 1.1 zu lassen. Aber die cc-community nutzt wohl noch SSL 3.1, deswegen scheitern Verbindungen dann hier. Aber ich bin kein Fachmann.

Gruß
SpRuZ

//Edit: Ich sehe gerade, dass der Fuchs meine Änderungen nicht übernommen hatte. Jetzt ist RC4 raus.
 
Zuletzt bearbeitet:
QuicksandF

QuicksandF

( ͡° ͜ʖ ͡°)
@SpRuZ Die Cipher und Protokolle die dein Browser unterstützt sind nicht nur da um dich zu ärgern. Auch wenn in der Computerbild oder irgendeinem Blog steht das man die deaktivieren soll ist es meiner Meinung nach keine gute Idee. Man darf sich dann auf jeden Fall nicht wundern wenn viele Seiten nicht mehr richtig funktionieren.
OpenSSL unterstützt TLS 1.1 und 1.2 erst seit Version 1.0.1 aus März 2012. Einige Linux-Distributionen haben noch eine ältere Version und auf solchen Servern ist TLS 1.0 leider das einzig praktikable.

@Opik Mit dem SSLLabs server test sieht man schön was es bezüglich der SSL Konfiguration noch zu optimieren gibt.
  • Das "Addtrust External CA Root" Zertifikat mit dem Hash 02faf3e291435468607857694df5e45b68851868 ist unnötigerweise mit im Zertifikat eingebunden. Damit wird bei jedem SSL Handshake ~1KB mehr übertragen als notwendig. Das Zertifikat wird nie benötigt weil es die Browser bereits selber mitbringen. Clients vertrauen nie vom Server gesendete Root-Zertifikate. Dies ist der Fehler "Contains anchor" im Test.
  • Als Protokolle sind nur SSLv3 und TLS 1.0 aktiv. Spätestens seit POODLE sollte SSLv3 auf dem Server komplett deaktiviert werden. Seit OpenSSL 1.0.1 aus März 2012 wird auch TLS 1.1 und TLS 1.2 unterstützt die um einiges sicherer sind als TLS 1.0. Es sollte daher OpenSSL aktualisiert werden und in der nginx config das hier stehen: "ssl_protocols TLSv1 TLSv1.1 TLSv1.2;". Neben allen aktuellen Distros haben auch die CentOS und Ubuntu Vorgänger ausreichend aktuelle OpenSSL-Versionen. Nur der Vorgänger der aktuellen Debian-Version (also squeeze) hat noch ein altes OpenSSL. Falls dies eingesetzt wird könnte langsam mal auf wheezy aktualisert werden... :)
  • Zusätzlich kann man im nginx super simpel das SPDY Protokoll aktivieren, einfach statt "listen 443 ssl;" schreiben: "listen 443 ssl spdy;" und restart. Besonders bei einem Forum mit den ganzen kleinen Profil-Bildern sollte das Geschwindigkeitsvorteile bringen da eine TCP-Verbindung für die Übertragung vieler Dateien genutzt wird.
  • Damit Browser beim Aufbau der SSL-Verbindung nicht erstmal den Comodo-Server fragen ob das Zertifikat noch gültig ist sollte OCSP stapling aktiviert werden, damit cacht der cc-community.net Server die OCSP-Daten und sendet sie direkt beim Verbindungsaufbau mit. Zusammen mit einer Optimierung der SSL-Performance bzgl. Latenz im Vergleich zu dem default Datendurchsatz kann die Config dafür so aussehen:
Code: 
ssl_stapling on;
 ssl_stapling_verify on;
 resolver 8.8.8.8 8.8.4.4 valid=300s;
 resolver_timeout 10s;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 60m;
ssl_buffer_size 4k; # Reduce Time-to-first-byte
  • Zu guter letzt sollten beim HSTS-Header noch die Subdomains inkludiert werden: add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
Wenn dann auch noch IPv6 aktiviert wird bin ich vollständig zufrieden. Edis unterstützt ja IPv6 zumindest bei den KVM-Servern :D
Bei Fragen bin ich gerne per PM behilflich.

Grüße,
QuicksandF
 
Opik

Opik

Team (Technik)
Mitarbeiter
Das stapling lohnt sich? Ich dachte die Route nach Russland ist der Hauptfaktor des Delays?
 
Opik

Opik

Team (Technik)
Mitarbeiter
IPv6 wird so schnell nicht kommen, da ich das Backend Routing ändern müsste.
(Unser Frontend Server ist kein Proxy)
Dafür habe ich aktuell keine Zeit bzw. der Druck/Nutzen ist mir nicht groß genug.

Das gleiche gilt für SPDY.
 
Status
Für weitere Antworten geschlossen.
| Info | IT-News | Tech | OT |
Oben Unten