Entwicklung Firefox

    Irgendwie habe ich zur Zeit richtig Probleme mit den Nightlies. Einige Seiten werden nicht richtig dargestellt (z.B. die Flash-Download-Seite und die Outlook.com-Kontakte), oder gar nicht (wie der Outlook-Kalender). Ausserdem kann ich mich bei einigen Seiten nicht mehr einloggen (z.B. Payback), da kommt ne Meldung : This Connection is Untrusted.
    http://www.payback.de uses an invalid security certificate. The certificate is only valid for http://www.payback.de (Error code: ssl_error_bad_cert_domain).
    This Connection is Untrusted bekomme ich auch auf anderen Seiten.
    Mir ist klar das es da immer mal Probleme geben kann, aber so gehäuft hatte ich das noch nie.

    Firefox Nightly, Windows 11 23h2

    Zitat von HeinzDo

    Irgendwie habe ich zur Zeit richtig Probleme mit den Nightlies.

    Und ?
    Da ein Nightly sowieso in einer produktiven Umgebung nicht eingesetzt werden sollte, ist das ein Nebenschauplatz.
    Ist halt momentan so.
    Falls es real stört und du an einer schnellen Lösung interessiert bist, magst du getrost Bugzilla besuchen.

    Zitat von Sören Hentzschel

    Solche Beiträge sind unnötig,

    Eigentlich dachte ich nicht so.
    Ein Nightly hat hier noch nie Probleme bereitet. Es kann zwar dann und wann zu Irritationen kommen, aber niemals zu Problemen, denn dann greift man beherzt auf das aktuelle Release zurück und tut das momentane Verhalten mit einem Zucken der Schultern ab.

    Es wurde "http://www.payback.de" genannt. Das ist zwar ein gültiger URL, aber es fehlt eine wichtige Information - das Protokoll. Wählt man nun http: ist die Reaktion eine andere als bei https:, denn nun zeigt sich ein gemischter Inhalt / mixed content. und da kann ein aktuelles Nichtly sehr wohl Unterschiede aufweisen.

    Zitat von .Hermes

    Im heutigen Nightly zeigt der Fx …

    Das Zertifikat benutzt kein subjectAltName, was durch RFC 3280 4.2.1.7 seit mindestens 2002 allerdings verlangt wird.
    So ziemlich jeder will solche nicht standardkonformen Zertifikate loswerden, Mozilla hat letzte Woche den Stecker gezogen. Weil es allerdings jetzt unerwarteterweise so viele Interop Probleme gibt wird der Patch vermutlich die Tage rückgängig gemacht und die betreffenden CAs kontaktiert.

    Relevante Bugs: 1088998, 1089527 1089104

    Ich muss sagen, dieses Forum scheint weitaus interessanter zu sein als es mir zuvor berichtet wurde.

    Wenn das alles so richtig ist, wie es im bug 1088998 steht, dann ist das Zurückziehen des Patches wohl vorerst die einzige Chance. Ich weiß ja nicht, wie viele solcher Wildcard-Zertifikate man als Anwender zu spüren bekommt. Ich weiß aber, dass geschätzt ca. 30% des weltweiten Internetverkehrs über Akamai-Server laufen. Da hilft dann auch der Hinweis auf den RFC nicht viel. Das ist ein richtig großer Player!
    Ich bin mal gespannt, wie die Lösung aussehen wird. Sämtliche First-Level-Subdomains in den AlternativeName zu packen, wird in diesem Fall sicher keine Option sein. Das klappt noch bei der Hausbank, aber bei einem solchen Unternehmen? Vermutlich ist der SAN deshalb in diesem Fall auch leer.
    Das zeigt einmal mehr, dass sich das Internet schneller verändert als man Protokolle definieren kann.

    Ich muss zugeben, mich freut das jetzt insgeheim, weil mir die Art der Spiegelung, wie sie Akamai und ähnliche Anbieter vornehmen, aus Datenschutzgründen immer etwas Unbehagen bereitet hat. Da hat es mit dem SSL schon immer ein wenig geknirscht.
    Gleichzeitig bin ich sehr beeindruckt, wie schnell sie in diesem Fall reagieren. Wirklich toll.

    Ich muss zugeben ich kenne mich mit Zertifikaten nicht sonderlich aus, allerdings hab ich auf deinen Post nochmal gegraben:

    Wildcards sind auch im SAN möglich, d.h. alle First-Level-Subdomains in den SAN zu packen ist gar nicht nötig.
    Siehe https://en.wikipedia.org/wiki/Wildcard_certificate und mal das Zertifikat von wikipedia/-media anschauen.

    edit: btw finde ich es deutlich schlimmer ein encoding aus den 80-ern zu benutzen (T.61)

    Zitat von Valerie

    ann ist das Zurückziehen des Patches wohl vorerst die einzige Chance.

    Für wen ?
    Mozilla will ja erstmals seine Benutzer nicht vor den Kopf stoßen, muss aber dennoch die gegebenen Standards respektieren.

    Jedoch können nur die diversen Betreiber den Knoten löschen, denn auch für sie gelten die identischen Standards. Doch die Notwendig zur Einhaltung ist bislang noch nicht zu ihnen durchgedrungen.

    Wenn der Patch also zurückgezogen wird, ist es nur eine zeitlich befristete Pause in der die Betreiber mal endlich in die Hufen kommen sollten,

    Nunja, Mozilla hat vor ein paar Tagen schon einen Patch zum strikteren HTTP 1.1 Framing aufgrund von Interop Problemen zurückziehen müssen (>10 Jahre alter Bug). Außerdem wird es jetzt eh erst mal einiges an Problemen mit alten SSL3 Server geben, da der SSL3-Support wegen POODLE abgeschaltet wird/wurde. Bug 1085138 wird spätestens ab dem 25. November massiv zuwachs erhalten wenn SSL3 auf dem Release-Zweig abgeschalten wird.
    So schön es sich auch vielleicht anhört die Kompatibilität zu solchen Relikten endlich aufzugeben, so finde ich Daniel Stenberg spricht mir aus dem Herzen: "I had a too positive view of the Internet"

    Zitat von .Hermes

    Für wen ?
    Mozilla will ja erstmals seine Benutzer nicht vor den Kopf stoßen, muss aber dennoch die gegebenen Standards respektieren.


    Nunja, der Standard erlaubt (glaube ich zumindest) Abwärtskompatibilität zu solchen Relikten. Allerdings wäre diese ein "MAY", wohingegen das Ausstellen solcher nicht "Baseline Requirements"-konformer Zertifikate ein "MUST NOT" ist.

    Einmal editiert, zuletzt von Yoyo_ (28. Oktober 2014 um 20:42)

    Zitat von Yoyo_

    Wildcards sind auch im SAN möglich, d.h. alle First-Level-Subdomains in den SAN zu packen ist gar nicht nötig.


    Ja, aber nur für eine Ebene in der Hierarchie. Der Workaround wäre, für alle anderen auf den SAN auszuweichen. Deshalb schrieb ich, dass das für eine Firma mit einem solchen Geschäftsmodell und der Größe wohl keine Option ist.

    Zitat von .Hermes


    Für wen ?


    Ich würde sagen für alle, die den Firefox benutzen und damit für Mozilla.
    Mach dich mal schlau, wer Akamai ist. Kaum jemand kennt sie, aber fast jeder von uns nutzt sie täglich.
    Wenn eine Firma, über deren Server rund ein Drittel des Traffics läuft, sich nicht im Detail an einen Standard hält, der bisher niemanden gestört hat und der für ihre Zwecke einfach nicht gut skaliert, dann kann auch Mozilla nicht mal eben von heute auf morgen auf dessen Einhaltung bestehen, RFC hin, RFC her..
    Wenn sie es da auf einen "Zweikampf" ankommen ließen, würden sie gewiss ordentlich Federn lassen.

    Zitat von .Hermes


    ist es nur eine zeitlich befristete Pause


    Ja, das steht auch so im bug. Akamai plant, das Problem bis Februar gelöst zu haben. Und das bei der Vielzahl an Zerts. Das finde ich eben sehr beeindruckend. Ich weiß nicht, ob eine Microsoft, Google oder Oracle ebenso reagiert hätten. Coole Company.


    Ach ja, Yoyo_, das Zitat mit dem "vor dem Kopf stoßen" stammte nicht von mir. Macht aber nichts.

    Noch ein Ach ja @ .Hermes, neben dem Riesen gibt es mit Sicherheit noch viele andere, deren Zert keine Alternative Subject enthält und deren Seiten dann im Firefox nicht mehr funktionieren würden, wohl aber in anderen Browsern. Was würde dann wohl passieren, wenn Mozilla sich hier stur stellen würde?

    Einmal editiert, zuletzt von Anonymous (28. Oktober 2014 um 20:43)

    So langsam geht es an der Thematik dieses Themas vorbei.

    Zitat von Yoyo_

    spricht mir aus dem Herzen: "I had a too positive view of the Internet"

    Aus meinem Herzen nicht.
    Es geht um die Sicherheit der Nutzer und die Zähigkeit oder das Durchhaltungsvermögens der Betreiber,

    Das Zitieren musst du noch üben.

    Zitat von Yoyo_

    Nunja, der Standard erlaubt (glaube ich zumindest) […]

    Kannst du zu diesem Glauben eine Fundstelle in den RFC nennen ?

    Zitat von Yoyo_

    wohingegen das Ausstellen solcher nicht "Baseline Requirements"-konformer Zertifikate ein "MUST NOT" ist.

    You hit the nail!
    Das Problem ist, es gibt CAs fast wie Sand am Strand. Darunter auch fragwürdige. Unter anderem deshalb führt Mozilla ja das Pinning ein, weil man manchen CAs inzwischen nicht mehr so wirklich trauen kann.

    Einmal editiert, zuletzt von Anonymous (28. Oktober 2014 um 20:54)

    An euch beide erstmal: Sorry für das falsche Zitat und danke für den Hinweis. Bin normal auf mozillazine unterwegs, und nicht hier im deutschen Forum. Komischerweise war das Zitat geschachtelt und ich hab wohl den falschen Tag entfernt. Ist korrigiert ^^
    .Hermes: Ich bezog mich hierbei auf einen Entwickler von Chrome der auf RFC 2818 gelinkt hat und vor einem Jahr im äquivalenten Chromium-Bug schrieb:

    Zitat

    RFC 2818 discouraged the practice > 10 years ago, as it was only intended for legacy. The Baseline Requirements require a subjectAltName, and require that the only host-ish names in a CN must be a name also in the SAN.

    Ich schau mal schnell über das RFC ob ich die Stelle finde...
    Und btw. das spricht mir aus dem Herzen sollte eher ein "spricht mir aus meinem blutenden Herzen" sein aka es tut doch sehr weh zu sehen wie viel solcher Relikte noch am laufen sind und kritische Infrastruktur ausmachen.

    Btw. an euch beide: Brian Smith hat vor ein paar Minuten angekündigt den relevanten Patch wieder rückgängig zu machen und es werden neue Nightlies kompiliert.

    edit: Hier der Quote aus dem RFC von Mai 2000:

    Zitat

    If a subjectAltName extension of type dNSName is present, that MUST
    be used as the identity. Otherwise, the (most specific) Common Name
    field in the Subject field of the certificate MUST be used. Although
    the use of the Common Name is existing practice, it is deprecated and
    Certification Authorities are encouraged to use the dNSName instead.

    Also eine vor bereits über 14 1/2 Jahren veraltete Praktik... scheint das zu sein was hier gemeint ist. Disclaimer: Ich bin kein Experte in solchen Dingen ^^

    Zitat von Yoyo_


    Also ein vor bereits über 14 1/2 Jahren veraltetes Verfahren

    Danke! Was für eine schöne Diskussion.
    14 1/2 Jahre, das ist auf den ersten Blick eine lange Zeit, gerade wenn man das atemberaubende Tempo des Internets berücksichtigt. Wenn ich allerdings wirklich einmal soweit zurückdenke, dann stelle ich fest, dass damals nur ein Bruchteil der heutigen User online war. Die meisten der Leute, die hier mitlesen, waren es vermutlich nicht.

    Das Internet sah auch noch ganz anders aus als heute. An Einkaufen, twittern, whatsappen usw. war gar nicht zu denken. Selbst Google kannte damals kaum jemand.
    Ein RFC, der aus dieser Zeit stammt, sollte grundsätzlich hinterfragt werden. In diesem Fall nicht in puncto Sicherheit und Relevanz. Man muss doch nüchtern feststellen, dass solche Sicherheitsaspekte der Mehrheit egal waren und heute noch sind. Selbst Mozilla kommt erst dieser Tage drauf, dass sich viele Webseiten nicht konform verhalten. Da kann man den Betreibern der Webseiten keinen Vorwurf machen. Eher den Anwendern, denen das alles ...egal war und ist.

    Nunja, das ist auch das Original RFC, und noch kein Standard, bzw. nur ein Informational Document, das in dem Part auf dem 1999-er RFC 2459 aufbaut welches seitdem durch das RFCs 3280 (2002) und daraufhin 5280 (2008) ersetzt wurde, das zuletzt 2013 mit RFC 6818 aktualisiert wurde, in dem u.a. bezüglich der Kodierung nun IA5String als MAY und UTF8STRING als SHOULD deklariert wird.

    Zum Vergleich: Die hier nicht funktionierenden Zertifikate sind TeletexString (T.61) encoded, und das wurde bereits 2006 in RFC 4630 als Update zum RFC 3280 als deprecated und nurnoch zur Abwärtskompatibilität zu verwenden genant.
    Und noch früher: Im 1999er RFC 2459 findet sich bereits diese Aussage über die TeletexString Enkodierung:

    Zitat

    The TeletexString and UniversalString are included for backward
    compatibility, and should not be used for certificates for new
    subjects. However, these types may be used in certificates where the
    name was previously established. Certificate users SHOULD be
    prepared to receive certificates with these types.

    Nicht nur die Praktik bezüglich des Common Names statt SAN ist also hoffnungslos veraltet, sondern das Encoding ebenso bereits seit Januar 1999, d.h. über 15 Jahre...

    Wie kommt es eigentlich dass all die Zertifizierungsstellen so einen Riesenmist verzapfen? Was für Software benutzen die denn um ihre Zertifikate zu erstellen? Sind das alles Bugs in OpenSSL oder benutzen die Versionen aus den frühen 2000-er Jahren? Das erinnert mich an die legacy PHP-Applikation an der ich gerade arbeite... Alles ist katastrophal programmiert, es gibt keine generellen softwarearchitekturiellen Richtlinien, SQL-Injections en'masse und doch funktionierts. So verhält sichs momentan mit dem Internet. Viele alte Relikte die Stück für Stück anfangen dem großen Ganzen zu schaden.
    Meine Hoffnung liegt auf HTTP/2, TLS 1.3 (v.a. ECC), neuen Ideen zu Zertifikatsverwaltung (cert/pubkey pinning) von Seiten der Technologie und Organisationen wie Mozilla, der IETF und EFF, alles in die richtigen Bahnen zu lenken.

    Valerie, in gewisser Weise hast du Recht, vielen sind all diese Sicherheitsaspekte egal. Allerdings kann man das auch nicht direkt erwarten. Es gibt schließlich kein Schulfach "Sicherheit im Internet". Ziel ist es deshalb Tech Evangelism = Aufklärung zu betreiben, allerdings muss das nicht zwangsläufig bei den Anwendern geschehen. Dem ist es aus Anwendersicht erstmal gleich ob sein Browser per SSL3+RC4 oder TLS1.2+[PFS-Algo] mit einer Webseite verbindet. Ihm wird meinetwegen in der Adresszeile angezeigt das die Verbindung zu seiner Bank nicht sicher ist, aber wird er sich deshalb an seine Bank wenden und wenn, wird diese Ratschläge/Hinweise von einem Kunden einfach so aufnehmen? Beide Seiten sind für gewöhnlich zu faul irgendetwas zu tun. Auf Bankenseite wären Gesetze vielleicht eine Hilfe, aber wenn man sich unsere Regierung oder die EU anschaut.... Internet = Neuland :(
    Deshalb gilt: Die Infrastruktur muss inhärent sicher werden und auch gehalten werden. Leider sind CAs wie du schon angemerkt hast wie Sand am Strand vorhanden, und viele sind einfach überfordert oder unfähig. Einiges davon ist auch sicherlich Software wie OpenSSL zu zuschulden, welche "Kryptographie schwer macht". Ziel wird es sein in den nächsten Jahren "Cryptography for the Masses" zu designen, sodass jeder, ob Anwender, CA, Programmierer sichere Anwendungen schreiben, Zertifikate ausstellen und Software bedienen kann, ohne ein Diplom/Master/etc.pp. in Mathematik oder Kryptographie zu haben. Wieder ein beispiel aus meiner legacy-PHP-App: md5+salt gehashte Passwörter. Selbst implementiert. Früher hatte man eben keine password_hash/_verify Funktion, welche es mittlerweile in PHP gibt und die Kryptographie einfach macht. Anyway, ich mach jetzt mal Schluss mit diesem völlig unstrukturierten Text/Rant... Muss ja auch irgendwann schlafen und das ganze divergente Denken resultiert nur in noch mehr strukturlosen (wikipedia quote) "lengthy discourse by a single performer, especially if irritated or upset".

    edit: von mir auch Danke für die schöne Diskussion. Hat mich gefreut :)

    edit2: Nächster Tag, und ich hatte Lust nochmal schnell nachzuschauen:

    OpenSSL enkodiert seit Ende 2005 standardmäßig in utf8string:
    https://github.com/openssl/openss…c40b6553faa1216

    D.h. die CAs benutzen veraltete config files oder haben seit 2005 ihre OpenSSL-Version nicht aktualisiert -.-
    Allerdings siehts auch so aus als ob alle Optionen zum subjectAltName selbst heute noch standardmäßig ausgeschalten sind.
    Außerdem hosted bspw. selbst das MIT noch eine veraltete Config aus vor 2005: http://web.mit.edu/crypto/openssl.cnf
    Und das ist das vierte Ergebnis wenn man nach openssl.cnf googelt. Die OpenSSL-Dokumentation ist auch hoffnungslos veraltet (https://www.openssl.org/docs/apps/req.html siehe string_mask) und reflektiert das Update aus 2005 nicht.
    Interessanterweise hat das bereits einigen die Nerven gekostet, welche Ihre Zertifikate signieren wollten:

    http://www.muck.net/161/signing-cs…ld-be-printable
    https://stackoverflow.com/questions/6976…cate-with-my-ca

    Grauenvoll.....