Nico
former person of interest
|
Mozilla will HTTP ausrangierenIn einem Blog-Eintrag hat Mozilla angekündigt, unsicheres HTTP in Zukunft nicht mehr unterstützen zu wollen. Neue Firefox-Features sollen dann nur noch Seiten zugänglich gemacht werden, die per HTTPS verschlüsselt übertragen wurden. Link: www.heise.de Bin dafür.
|
smashIt
master of disaster
|
solang man es in der about:config abdrehn kann bin ich dafür
|
Dreamforcer
New world Order
|
oder halt ein riesiger button der die seite dann doch öffnen lässt
|
Obermotz
Fünfzylindernazi
|
Wird auch Zeit.
|
mat
AdministratorLegends never die
|
Es ist die Zukunft, keine Frage. Jetzt muss nur noch dasselbe mit IPv6 gemacht werden. Weil SSL-Zertifikat bei Name-based Hosting braucht immer eine eigene IP pro Webseite und die werden langsam teurer als die Zertifikate selbst.
Und günstigere Wildcard-Zertifikate wären auch ein Hit.
|
Redphex
Legend RabbitOfNegativeEuphoria
|
Es ist die Zukunft, keine Frage. Jetzt muss nur noch dasselbe mit IPv6 gemacht werden. Weil SSL-Zertifikat bei Name-based Hosting braucht immer eine eigene IP pro Webseite und die werden langsam teurer als die Zertifikate selbst. Ist das nicht nur ein Apache Leiden? nginx hat diese Einschränkung nicht.
|
mat
AdministratorLegends never die
|
Mit SNI kann man das umgehen, das muss allerdings der Web Server (nginx, Apache >= 2.2.12) und der Browser unterstützen. Aber du hast recht, heutzutage kann man für eine Webseite wie zB oc.at die Limitierung umgehen. Ein normaler Hoster wird wahrscheinlich noch abwarten.
|
COLOSSUS
AdministratorGNUltra
|
Spaetestens seit dem da-facto-Tod von SSLv3 durch POODLE gibt es keinen fuer mich nachvollziehbaren Grund mehr, auf SNI zu verzichten - jeder mir bekannte TLS-Stack, der das Protokoll in mindestens Version 1.0 unterstuetzt, versteht auch SNI.
Bei GH waren wir stets EXTREM konservativ was die Unterstuetzung alter UAs und auch TLS/SSL-Stacks angeht (IE6-auf-WinXP-Kompat. war bis zu POODLE z. B. ein entscheidendes Kriterium, ob ein neues Feature online gehen kann oder nicht), und wir haben damals auch die Entscheidung gefaellt, dass SNI fuer uns ab jetzt/damals "OK" ist.
|
mat
AdministratorLegends never die
|
Gut zu wissen, danke.
|
COLOSSUS
AdministratorGNUltra
|
(Unabhaengig von weitverbreitetem SNI-Support finde ich quasi-erzwungenes HTTPS ueberall uebrigens eine ziemlich depperte Idee. Es gibt ja auch andere Methoden, uebertragenen Content vor Verfaelschungen und/oder Eavesdropping zu sichern, der sich nicht auf TLS und das kaputte X.509-CA-System verlaesst; mittels GPG z. B. - vgl. auch https://www.varnish-cache.org/docs/...ical-postscript)
|
Smut
takeover & ether
|
ich kann der idee auch nichts abgewinnen. vorallem weil ja die CRLs ja großteils per http ausgeliefert werden. da habens ein paar profis sitzen. bei der zertifikatsvalidierung muss ich (ich weiß dass es google nicht mehr macht) die CRL abrufen. wenn die CRL per SSL abgerufen wird, muss ich auch das zertifikat der zugrundeliegenden SSL-verbindung für die CRL-file vorab validieren. das wird zum henne ei problem, außer ich truste dem signaturgeber der CRL file nur können dann nur noch die root-cas die crls signieren - die sind aber großteils offline und signieren ausschließlich die intermediates bzw. CRLs mit längerer gültigkeit. edit: abgesehen davon werden dann sachen wie SSL-inspection unabdingbar für viele unternehmen. der druck es zu erlauben wird ziemlich groß. im endeffekt ist dann die situation schlechter als sie aktuell ist. nur nur damit ein 0815 blogger, wikipedia und amazon auch per SSL ihren "schützenswerten" content ausliefern? klar kann SSL die privacy schützen, das kann aber wohl kaum ihr anreiz sein: dann müssteich mozilla und google eine doppelmoral unterstellen, da sie genau mit diesen daten ihre produkte finanzieren.
Bearbeitet von Smut am 04.05.2015, 16:54
|
Luka
Vereinsmitglied...
|
CRL wurde von OCSP abgelöst und die OCSP-Response ist auf jeden Fall signiert.
|
Smut
takeover & ether
|
bist du dir sicher dass crl abgelöst ist? ich habe eher die befürchtung dass certificate revoking nicht ordentlich funktioniert, da es viele clients aus performance gründen nicht überprüfen, als dass OCSP CRLs tatsächlich ablösen wird. edit: abgesehen davon: was bringt es eine CRL verschlüsselt zu übertragen? das ist public information, die man ohnehin nicht verheimlichen kann wenn dem eine SSL-handshake mit einer IP vorhergeht. die CRL ansich ist ja auch signiert - nur könnte man sie später nicht mehr per HTTP abholen.
Bearbeitet von Smut am 04.05.2015, 17:06
|
Luka
Vereinsmitglied...
|
Ich bin auf jeden Fall für HTTPS überall! Alternativen wie GPG mit Web of Trust oder z.B. Convergence sind (noch) nicht massentauglich. Andere Systeme haben die gleichen Henne-Ei-Probleme, CRL usw. Edit: Mit Henne-Ei-Problem meinte ich den Austausch des öffentlichen Schlüssel. Das Zertifikatsystem stellt genau dies sicher. Angenommen ich will jemanden eine Datei mit GPG verschlüsselt schicken. Dafür benötige ich seinen öffentlichen Schlüssel und er meinen, damit er meine Signatur überprüfen kannst. Wie tauscht man die öffentlichen Schlüssel sicher aus, wenn wir uns noch nie getroffen haben?
|
Smut
takeover & ether
|
bin dagegen, da dadurch nur noch viel mehr insecure CAs aus dem boden gestampft werden ohne einen mehrwert an sicherheit zu bieten. es wird sogar noch unsicherer weil diese insecure CAs, dann aufgrund schlechter prüfungen ein zertifikat für von mir aus google.com ausstellen können. diese probleme muss man zuerst adressieren. hier wird durch die finanzierung von CAs blödsinnig geld verbraten.
das henne ei problem ist ja künstlich geschaffen, da man eine public information, die auch aus privacy sicht nicht abstreitbar ist, plötzlich ausschließlich über SSL verschicken will.
edit: abgesehen davon funktioniert OCSP aus dem von mir genannten grund genauso über http wie CRL.
Bearbeitet von Smut am 04.05.2015, 17:15
|