Kristian Koehntopp wrote: > > Ich erwähnte schon, daß es an brauchbaren Implementierungen mangelt. > > Deswegen muß aber nicht das Konzept an sich unbrauchbar sein, nur > > etwas unpraktikabel. > > Als Seitenlinie unserer Diskussion über ASN.1 bzw. binäres XML > und "die Folgen":
Die Folgen sind spaetestens seit den ASN.1-bedingten SNMP-Bugs bekannt. Deshalb sind die existierenden Implementierungen auch nicht brauchbar. Die OpenSSH-Entwickler entfernten in Version 3.5 nicht ohne Grund die Abhaengigkeit vom ASN.1-Parser von OpenSSL (er wurde zuvor zur Pruefung des Paddings in RSA-Signaturen verwendet). > Das Problem sind nie die korrekten Daten, sondern die defekten. Das Problem sind nie die Daten, sondern die Parser. > ASN.1 kennt jedoch auch Containertypen, etwa Arrays oder > Structe. Hier sind die Nutzdaten selber wieder (Typkennung, > Länge, Nutzdaten)-Sequenzen. Es ist nun möglich, defekte > ASN.1-Pakete zu konstruieren, in denen die Summe der Längen der > Daten in einem Array nicht mit der angegebenen Gesamtlänge des > Containers übereinstimmt. Die meisten Binaerprotokollen haben diesen Effekt, z.B. auch BGP (ja, im Netz geistern PDF-Folien von einem Vortrag herum, in dem Behauptet wird, ein Teil der getesteten Implementierungen Probleme haben.) > Ein wissender ASN.1-Reader kann sich auch nicht auf die > Längenangabe im ASN.1-Record verlassen, um Speicher zu > bestellen. Doch, kann er, wenn ich die Spezifikation richtig verstehe. Die erzeugten Strukturen muessen AFAIK konsistent sein (sonst koenntem an ueber sie ja auch gar keinen Hash ausrechnen). Also kannst Du inkonsistente Daten gleich verwerfen.