[archimedes] Re: Messenger und SSL/TSL
- From: Raik Fischer <raik_fischer@xxxxxxxx>
- To: archimedes@xxxxxxxxxxxxx
- Date: Sat, 05 Jul 2014 14:06:19 +0200
Maximal ein Teilproblem, weil wenn ich Deine Tools nicht nutze und
stattdessen den SecureSocket von RCOMP habe ich vergleichbare Fehler.
Du vergißt, daß ein GAG-Mitglied dieses Jahr eine nicht unerhebliche Zeit
seines Lebens damit verbracht hat, den R-Comp-Code neu zu compilieren. Dabei
fehlten Bibliotheken, was das Ganze bislang scheitern ließ, soweit ich
richtig infromiert bin. Das Teil ist (so habe ich gerade nachgeschlagen) mit
GCC compiliert, obwohl auf einer Code-Lizenz basierend, die eher BSD
entspricht, was mich bei R-Comp, die Ihre Produkte ja auch für den PC-Sektor
anbieten, nicht wundert, da hier Norcroft C/C++ nicht weiter hilft. So ganz
würde ich das Thema nicht abhaken, wenn der Fehler in einer sonst selten im
RISC OS Sektor genutzten genutzten GCC-Library schlummert.
Ok. Dann wäre die erste Parallele GCC und die zweite wahrscheinlich
gleiche verwendete Librarys. Im Ergebnis würden dann vergleichbare
Fehler generiert.
Du hast Empfangsfehler ohne Messenger Pro Beteiligung gehabt und die Fehler
sehen erschreckend ähnlich zu denen der Messenger Pro Seite aus. Entweder
ist das eine optische Täuschung, die im Protokoll begründet ist, d.h. ein
Byte aus welchen Gründen auch immer falsch sorgt automatisch für einen
fehlenden Block es könnte aber auch eben ein Bibliotheksfehler sein.
Wenn man eine Mail mehrfach sendet werden immer neue Base64 Dateien
generiert/codiert, die nie gleich sind, wenn ich das richtig gesehen
habe. Vergleichen ist da schwierig. Die Fehlerhaften Dateien haben immer
mindestens einen "Zeilesprung", die ohne Fehler nicht. Die intern vor
dem wirklichen Senden erstellten sehen immer gut aus und werden von
verschiedenen Mailern (MPro 5-7; Thunderbird (WIN, LIN)) auch problemlos
geöffnet (ich habe das af einem Stick gesichert und den versch. vogeworfen).
In vielleicht max. 10% der Fälle wird die fehlerhafte Mail auch grösser.
Auch da konnte ich noch keine Regel erkennen. Dann wäre da noch mein
Biotop. Möglich, daß das bei Euch anders aussieht.
Und es fällt evt. noch was auf. Wenn ich die E-Mails bislang richtig verfolgt
habe, sind 126 Bit Verbindungen wohl nicht betroffen, wohl 256 Bit
Das habe ich so direkt noch nicht geprüft, weil ich unter RISC OS mit
arcor unverschlüsselt sende und empfange.
Verbindungen. Wie groß ist mittlerweile der in Deutschland erlaubte
Schlüssel? Früher waren es mal 56 Bit, aber die Zahl soll angehoben worden
sein. Nicht daß da ein deutscher Provider aufgrund gesetztlicher Bestimmungen
bei 256 Bit rein zufälligerweise "Strange Effects" auftreten läßt.
Um bei Deiner "Verschwörungstheorie" zu bleiben, wäre es für den
Provider leicht nur "erlaubte" Verschlüsselung zu verhandeln. Vielleicht
machen die das bei den gängigen BS auch und RISC OS ist wieder anders...
Allerdings müßte LINUX dann auch ähnliche Probleme haben.
s.o.
Evt. kann Alexander ja nochmal eine Variante breitstellen, mit der sich die
256 Bit Verschlüsselung ausschliessen läßt.
So wie ich das verstanden habe, hat er keinen Einfluß auf die
Verhandlungen wie die Deutschen 1919 in Versailles.
Es kann ja sein, das irgendein bei dem von Alexander verwendeten Port nicht
ausgewertes Bit bei der Verschlüsselung signaliert: Dies sind
"Nachrichtendienst konforme" 256 Bit, und die heute üblichen LINUX Varianten
erkennen das Bit und schliessen das Protokoll automatisch aus der Auswahl
aus. Aber unsere ältere Variante (auch die von R-Comp) sagt dann munter "ja
kann ich" und schon haben wir den Salat.
Ich hätte vorher weiterlesen sollen ;-)
Dagegen spricht das bevorzugte Auftreten des Fehlers auf einer bestimmten
Hardware. oder?
Da keiner weiß wie das generiert wird...
Jeffrey generiert aus der Prozessor ID für xM und Panda die MAC. Wer
weiß was noch so alles abgefragt werden kann.
Ich weiß nicht, ob ich meinen NAS mal dazu bringen kann, die für T-Online
Verschlüsselung preiszugeben.
Vielleicht kann man die bei Linux oder WIN auch irgendwo finden. Es wird
doch jeder Quatsch temporär abgelegt.
Raik
Other related posts:
