Beiträge von Yoyo_

Zitat von .Hermes

Eine instabile Version mit eine anderen instabilen Version zu kombinieren mache ich nie.

Verständlich. Instabile Versionen zu kombinieren verdoppelt schließlich die Probleme.
Jedoch geht es hier im Entwicklungsversionen, und nicht um instabile Versionen. Du kannst das englische "stable" im Kontext der Entwicklungsversion einer Software nicht einfach negieren und "instable" draus machen.

"Stable" heißt nicht "Software ist stabil", im Sinne von "Stürzt nicht ab" etc., sondern "Stabil" im Sinne des Quellcodes, der in einem stabilen (= änderungsarmen) Stadium angekommen ist.

Da in einer Entwicklungsversion viele Änderungen anfallen macht es nur Sinn gleichzeitig Entwicklungsversionen davon abhängiger Software zu benutzen. Schließlich finden sich Updates, welche aufgrund von bspw. API-Änderungen in der Entwicklungsversion der zugrundeliegenden Software nötig sind, gar nicht oder nur verzögert in der Release/Stable-Version der darauf aufbauenden Software wieder.

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.....

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

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.

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 .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