Impressum Datenschutz
News   Magazin   Börse   Links   ArcArchie   Homepages
 News  Home 

In eigener Sache: https

 <   >

Der lange überfällige Serverumzug von ArcSite wurde nach tagelangen Arbeiten heute umgesetzt. Der nächste Umzug wird hoffentlich nicht so umfangreiche Änderungen enthalten. Neben vielen kleinen und größeren Änderungen unter der Haube ist die Einführung von https wohl die wichtigste Änderung. Im Gegensatz zum früheren Vorhaben ist die Verschlüsselung optional. Da Fresco, Browse, Phoenix, Oregano 1 und Oregano 2 leider nur sehr veraltete und unsichere Verschlüsselung unterstützt, habe ich so gemacht. Diese alten SSL Verschlüsselungen werden nicht unterstützt.. Damit kann unter RISC OS nur NetSurf und vermutlich Firefox die Seiten mit https://www.arcsite.de/ anfahren. Browser wie Opera, Firefox und Chrome haben mit den moderneren Verschlüsselung TLS keine Probleme.

Damit man nicht von verschlüsselter Seite per Klick auf einen Link auf eine unverschlüsselte ArcSite Seite gelangt, musste ich sehr viele Links auf ArcSite ändern. Ich hoffe dabei ist mir kein Fehler unterlaufen. Falls jemand so einen Fehler findet, sollte mir bitte die Seite nennen die den falschen oder fehlerhaften Link enthält. Dazu einfach auf der Startseite unten auch Kontakt klicken und melden. Bei den sehr alten ArcSite News wurden die Links nicht korrigiert. Das kommt vielleicht in einer ruhigen Stunden.

Zusätzlich können die vielen RSS Benutzer nun auf den Feed mit https Links wechseln.

Also ändert eure Lesezeichen und fügt das "s" ein, damit die Feinde der Freiheit etwas mehr Kosten haben.

Wenn ich die noch bestehenden Probleme gelöst habe, kann ich mich wieder mehr um die Inhalte bei ArcSite kümmern.
cms, 22. 02. 2015, 16:43 Uhr <   >
Danke für die ganze Arbeit cms!
Patric, 22. 02. 2015, 16:57 Link
Vielleicht stehe ich jetzt auf dem Schlauch, aber... Wofür ist die Verschlüsselung gut? Es werden doch wohl keine privaten Daten, sondern öffentliche Inhalte angeboten / übertragen, die jeder lesen können soll und kann.
Isip, 22. 02. 2015, 17:07 Link
Deshalb hatte ich mal kurz keinen Zugriff...
Doofe Frage, was ist der Mehrwert, wenn ich "unsicher" weiter nutzen kann?
Raik, 22. 02. 2015, 17:10 Link
Ja, das mit der Verschlüsselung stimmt weitesgehend. Aber ich habe noch Zugänge um zum Beispiel ArcSite News zu veröffentlichen. Zusätzlich ist der Mailverkehr inklusive Abholen und Senden von meiner Seite nun mit den selben Zertifikat verschlüsselt. Da Messenger die gleichen Probleme wie Fresco, Browse und so weiter hat, muss ich da noch an einer Lösung arbeiten. Da ich IMAP nutze kann ich nicht mit deinen POP3S und SMTPS arbeiten. Ich werde wohl meinen Raspberry Pi dafür opfern müssen um über Linux mit stunnel eine vernüftige Verschlüsselung zu erhalten.

Ansonsten, alles was dem fünfäugigen Monster Arbeit macht und wenn die unnötig ist, ist eine gute Sache. [zwei Finger nach oben, Handrücken nach vorn]
cms, 22. 02. 2015, 17:23 Link
Ich finde es sehr wichtig, dass man weiterhin Fresco oder Browse bei ArcSite benutzen kann. Ich kenne auch mindestens einen, der mit einen Risc PC Fresco nutzt.

BTW: Das Problem bei De-Mail ist, dass die Ende-zu-Ende-Verschlüsselung "für" den Virenscan aufgebrochen wird. Das ist dann genau die Stelle wo NSA, BND und so weiter mitlesen.
cms, 22. 02. 2015, 17:38 Link
Darüber, daß öffentliche Inhalte von riesigen bis klitzekleinsten Webauftritte massenweise auf https umstellen wundere ich mich schon seit Monaten.

Ich möchte hier eine, an dieser Stelle ungewöhnliche, doch sehr ernsthaft gemeinte Empfehlung aussprechen, die sich an alle richtet die mit dem Mainstream OS unterwegs sind: probiert mal den Webbrowser "360 Browser" aus. Ich habe Erfahrungen mit zahlreichen Browsern (ebenso auf Apple Systemen, mit Exoten und Tablets aller Art) und war noch niemals so zufrieden. Ich habe einige Extensions installiert: Auto-Reload, Check My Links, Cahoots, New Tab Redirect und Speak It.

Mit Fresco bin ich immer dann unterwegs wenn ich Texte weiter verarbeiten will z.B. Adressen über die Zwischenstation StrongEd per Drag & Drop aus dem Impressum holen.
Markus Huber, 22. 02. 2015, 18:22 Link
Manchmal befürchte ich, die Leute denken, TLS (Transport Layer Security) wäre ein Allheilsmittel. Ist es aber nicht.

Mir wäre lieber, man würde wesentlich längere Schlüssel verwenden, wie es mit GnuPG möglich ist, und den privaten Mailverkehr endlich ordentlich verschlüsseln. Dann würde die Arbeit für das fünfäugige Monster gleich exponentiell ansteigen. Die hätten beim derzeitigen Stand der Dinge dann wohl keine Chancen mehr, wenn das jeder machen würde. TLS dagegen ist da leider nur ein Tropfen auf dem heißen Stein.

Mein öffentlicher Schlüssel findet sich auf meiner Webseite. Paradoxerweise schickt mir fast niemand abgesperrte E-Mails, noch kriege ich verschlüsselte E-Mails ins Haus geliefert (insgesamt sind das 3 Leute, welche das tun). Dafür eine Webseite über TLS anbieten, mutet mich da merkwürdig an.

Danke, dass du auch noch an die Leute denkst, welche die Verschlüsselung nicht nutzen können oder wollen.
Isip, 23. 02. 2015, 06:05 Link
Natürlich ist TLS, früher hieß das SSL und wird nebenbei hier bei https nicht unterstützt, kein Allheilmittel. Aber GnuPG ist es auch nicht.

GnuPG wird für die Verschlüsselung von Mails genutzt und damit kann man auch Dateien verschlüsseln. Im Web und so weiter wird GnuPG nicht eingesetzt. Bei Mail wird die Nachricht selbst verschlüsselt. Der Header der Mail wird im Klartext übertragen. Im Header stehen der Absender, der Empfänger, der Betreff der Mail, der Weg der Mail und einiges mehr drin. Da ist schon ein guter Teil unlesbar geworden. Aber Absender, Empfänger und Betreff liegen damit im Klartext vor. Zusätzlich kann man im Header sehen welcher Mailclient genutzt wird und damit auch welches Betriebssystem. Das kann für die Platzierung von Trojaner nützlich sein.

Bei TLS wird der Transport vom Absender zum Mailserver des Mailproviders verschlüsselt übertragen. Man kennt damit nur die Absender IP, den Mailserver und die Länge der Mail. Auf dem Server des Providers wird die Mail in Klartext zwischengespeichert und in der Regel sofort an den Zielmailserver weitergeleitet. Ob die Verbindung zwischen dem Provider und dem Zielmailserver verschlüsselt ist, kann man als Absender nicht beeinflussen. Wenn zum Beispiel der Zielmailserver die Verschlüsselung nicht unterstützt, wird die Mail unverschlüsselt übertragen. Bei dem Zielmailserver wird die Mail im Klartext gespeichert. Der Empfänger kann dann mit POP3 oder IMAP die Mail abholen. Wenn er dabei Verschlüsselung nutzt, dann kann man in die Mail nicht hineinschauen. Kennt aber die IP des Empfängers und die Länge der Mail. Eine Zuordnung zwischen Absender und Empfänger kann etwas schwerer werden. Das liegt daran wieviel Mails der Mailprovider empfängt und versendet. Hier kann aber die Länge der Mails Hinweise geben.

Kombiniert man GnuPG und TLS und geht mal davon aus, dass in der gesamten Übertragung TLS genutzt wird, dann sind die Schwachpunkt beim Mailprovider und dem Zielmailserver, da diese die Mail im Klartext abspeichern. Bei GnuPG heißt Klartext, dass der Mailheader unverschlüsselt ist. Also Absender, Empfänger, Betreff (es gibt ja tatsächlich Menschen die einen vernünftigen Betreff angeben) und einiges mehr.

(Absender)-->[Mailprovider]-->[Zielmailserver]-->(Empfänger)

Auch die Kombination von GnuPG und TLS ist nicht ideal, da genau an dem Schachpunkten angesetzt wird. Auch wenn man den Inhalt nicht lesen kann, sind das schon einige Informationen. Eine Zuordnung zwischen Absender und Empfänger nicht unmöglich und die Länge der Mail verrät evtl. auch etwas.

Wenn Nachrichten direkt vom Absender an den Empfänger verschlüsselt gesendet werden, kennt man nur die Gesprächspartner und die Länge der Nachricht, wenn man dabei Verschlüsselung nutzt. Solch ein Protokoll gibt es aber nicht und hier gibt es auch das Problem, dass der Absender die IP Nummer des Empfängers braucht. Nameserver oder ein anderer Vermittlungsserver sind wieder Schwachpunkte. Mit Einrichtungen wie Tor könnte man zusätzlich die Beziehung zwischen Absender und Empfänger verschleiern.

Bleibt noch das Problem, dass der Absender und Empfänger die Nachricht irgendwie im Klartext vorliegen haben. Auch wenn die verschlüsselt gespeichert werden, gibt es noch Trojaner. Man kann sich also viel Mühe geben und wird nie absolute Privatheit erreichen. Aber man kann so viele Steine in den Weg werfen wie es geht um den Aufwand zu erhöhen.

Das schlimme ist, dass der ganze Aufwand nicht wegen Verbrecher wie die Mafia oder den Terroristen notwendig ist. Sondern von staatlichen Einrichtungen die mit unseren Steuergelder uns Bürger schützen wollen oder anscheinend müssen. Aber die Ereignisse in Paris zeigen auch, dass dieser Schutz unzureichend ist und man ganz andere Ansätze braucht. Aber da sind wir wieder bei Orwell und Co.

Zusätzlich wird bei Messenger Pro und GnuPG der Text verschlüsselt. Üblich ist aber schon seit längeren, das die Textnachricht als Anhang verschlüsselt wird. Bekommt man solche eine Mail mit verschlüsselten Anhang muss man den Anhang exportieren und mit GnuPG entschlüsseln. Schön wäre es, wenn das Messenger selbst macht. Möglich wäre es, dazu POP3S zu erweitern. Dann bekommt Messenger die Mails unverschlüsselt. Dann wird die eigentlich verschlüsselte Mail aber auch unverschlüsselt gespeichert. Aber da ist auch die kleine Hürde eines Betriebssystems jenseits von Windows, Mac OS und Linux.
cms, 23. 02. 2015, 11:29 Link
Dankeschön für die lange, ausführliche Erklärung. Insbesondere der letzte Absatz ist richtig; mit solchen Anhängen hatte ich auch schon viele Probleme. Kann aber auf der Seite des Senders abgestellt werden. Hier sind wir unter RISC OS anscheinend irgendwie verlassen.

Der von mir angedachte Unterschied zwischen TLS und GnuPG liegt ganz einfach in der Länge der Schlüssel, die bei GnuPG locker um ein 8-faches länger sein kann, womit eine Verschlüsselung der Inhalte ohne eingebaute Hintertürchen in absehbarer Zeit durch die Bruce-Force-Methode (alle Schlüssel ausprobieren) rein theoretisch derzeit so gut wie unmöglich sein dürfte.

Richtig ist, dass bei GnuPG weder die Transportdaten, noch der Betreff verschlüsselt werden. Das geht nicht, weil GnuPG kompatibel zum alten, hergebrachten Mailsystem sein soll. Um hier Abhilfe zu schaffen müsste man ein komplett neues Mailsystem schreiben, das nicht mehr zum alten System kompatibel ist, und ein System schaffen, das am besten die Transportdaten verwischt, sprich löscht.

Letzteres wird aber von den Behörden mit Sicherheit bekämpft werden. TLS bringt überhaupt nichts, weil die Verschlüsselung nur zum Mailserver des Dienstproviders aufgebaut wird, auf diesem aber sämtliche Daten im Klartext vorliegen (es sei denn, man hat z. B. GnuPG eingesetzt, dann werden wenigstens die Inhalte der E-Mail auch dort verschlüsselt übertragen). Laut Gesetz müssen die (Verbindungs)daten ein halbes Jahr lang gespeichert werden (ist das noch aktuell?). Die Behörden können sich bei Bedarf Zugriff auf den Mailserver von z. B. der Telekom verschaffen und sehen dann problemlos, wer wann mit wem kommuniziert hat usw. Eventuell sehen sie dann auch die ganzen Inhalte im Klartext, falls nicht zusätzlich verschlüsselt worden ist. TLS bringt hier also rein gar nichts, weil sich die Behörden sowieso Zugriff auf die Mailserver und damit auf die Klartextübertragung verschaffen können, wenn sie wollen. GnuPG hilft aber wenigstens noch ein bisschen was.

Gezeigt hat sich, dass, wann immer ein Dritter die Kommunikation bereitstellt (z. B. Facebook...), meist ein Hintertürchen für die Behörden offensteht, was offiziell aber natürlich bestritten wird.
Isip, 23. 02. 2015, 19:11 Link
Nachtrag: Es hat übrigens seinen Grund, warum die Schlüssel bei TLS offiziell auf 256 oder 512 Bit begrenzt sind (weiß nicht mehr, was gerade gilt) und längere Schlüssel offiziell nicht erlaubt oder zugelassen werden. Denn alles, was _wesentlich_ länger ist, macht derzeit selbst den schnellsten Rechnenanlagen Probleme beim Knacken. Schrieb das jetzt aus dem Kopf und weiß nicht mehr, wo ich das her habe. Wird aber wohl so sein.
Isip, 23. 02. 2015, 19:18 Link
Vorsicht, die Schlüssellänge ist nicht immer ein Zeichen der Qualität der Verschlüsselung. Zusätzlich ist TLS im Gegensatz zu GnuPG eine Verschlüsselung, die on-the-fly benutzt wird. Es ist nicht aktzeptable, wenn zum Beispiel eine Webseite ohne Verschlüsselung einen Sekunden braucht bis die im Browser angezeigt wird und mit Verschlüsselung 10 Sekunden braucht. SSL wurde ursprünglich von Netscape für Webseiten genutzt und das System wurde dann halt für Mail (SMTP, POP3, IMAP) und so weiter übernommen. Bei Mail hätte man durchaus mehr Zeit.

Wenn ich das richtig sehe sind aktuell 256 Bit die obere Grenz und damit Standard.
cms, 23. 02. 2015, 19:55 Link
Wer Interesse hat, kann ich gerne mitteilen wie man mit stunnel auf einen Raspberry Pi mit Linux gut verschlüsseltes IMAP hinbekommt. Das kann man auch auf POP3 oder SMTP übertragen und ist einfach und schnell umgesetzt.
cms, 24. 02. 2015, 21:54 Link
Wie kann ich meine Domain alt.de z.B. mit der .htaccess Datei auf eine "fremde" Domain (nehmen wir als Beispiel neu.de, auf einem anderen Server) so umleiten, daß der Browser in der URL weiterhin alt.de anzeigt, aber die Inhalt komplett vom neu.de Server geholt werden? Das müßte dann sogar so funktionieren, daß tiefer liegende Seiten, beispielsweise www.neu.de/bsp/..., die als lesbare URL in der Form www.alt.de/bsp/... aufgerufen werden, eben die Daten direkt von www.neu.de/bsp/... holen. Geht das?
Markus Huber, 25. 02. 2015, 14:24 Link
Hallo Markus,

das ist doch mal eine typische RISC OS Frage. :-)

Beim Apache Webserver heißt die Lösung Proxy. Vielleicht das hier oder Klick.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*?)$ http://www.alt.de/$1 [P]
cms, 25. 02. 2015, 14:51 Link
@cms: So funktionierts zwar noch nicht aber der Klick hat weiter geführt. Danke. Ich würde ja die richtigen Domains dahinter schon nennen wollen. Aber per Suchmaschine ist die Frage und der Domainname verknüpft und einfachst zu finden. Das unterwandert meine Reputation ;-)

Was anderes: http://www.coridiumcorp.com/prod-specs1.html
Dem ARM LPC1114 mit 50 MHz dichtet der Hersteller "Operates faster than 6 million BASIC lines per second" an. Während mein Favorit Klick, ein ARM LPC2136 mit 60 MHz, "nur" "Program Execution Speed: ~50,000 BASIC instructions/sec" leistet.

Wo kommen "plötzlich" die BASIC Sprachen her die auf den ersten Blick keine der alten Einschränkungen mehr haben. Wer hat in den letzten Dekaden an ARM BASIC Interpretern gearbeitet um die leistungsfähig zu machen? Oder sind die auf dem Datenblatt gut? Hat da wer Ahnung?
Markus, 26. 02. 2015, 10:41 Link
Einfacher wäre es wenn die alte Domain umzieht. Aber da wird es Gründe geben. Im Webserver muss ein oder mehrere Proxymodule eingebunden sein. Sehr gut möglich, dass der eine oder andere Provider sich den Platz im RAM spart. Kontakt mit dem Support kann hilfreich sein, wenn man einen Fachmensch erwischt.

Zu BASIC: Keinen Ahnung. Sind das "leere" REM-Zeilen? :-)
Ich selbst schätze das BBC BASIC als sehr schnell ein. OK, mit den moderen ARMs sind neben Neon usw. vermutlich noch ungenutzte Möglichkeiten vorhanden.
cms, 26. 02. 2015, 11:29 Link
Der Grund für die Domain Beibehaltung und dennoch Datenumzug ist einfach: Tochter mit eigenem weltweit bekanntem Namen = Domainname bei eigenem Provider mit Eigenschaften des Mailservers die von der Tochter unbedingt behalten werden wollen und dürfen. Muttergesellschaft deren Verantwortliche darauf bestehen, daß der Webserver der Muttergesllschaft verwendet wird, das Webdesgin komplett von der Markenmutter übernommen und im Aussehen angepaßt wird. Die Tochter hatte eine sehr persönliche Wahrnehmung, die Mutter will kein Kontaktformular, kein Forum, keine öffentlichen Antworten etc. Stattdessen ein Webauftritt der den Eindruck macht alles so schön hier, aber im Hintergrund so viel Firewall wie möglich, damit bloß kein Kunde Arbeitszeit kostet.
Markus, 26. 02. 2015, 11:52 Link
Erster Tipp: die "6 million BASIC lines" sind nicht BASIC als Sprache sondern "basic lines" = Grundbefehle. Also ARM Code. Hat man halt mal eben nur Groß/Kleinschreibung verbuchselt. Zwar in einem Kontext bei dem das entscheidend ist, aber das kennen wir ja aus der Politik.
Markus, 26. 02. 2015, 11:55 Link
Töchter, Mütter? Was ist mit den Vätern und Söhnen? ;-)

Kann der alte Webserver PHP? Dann versuch das Skript per Klick unter "Beispiel". Nenne die Datei nicht "info.php" sondern "fZgjk-gdElk_3gk.php" oder so ähnlich und lösche die nach Gebrauch. Kann aber sein, das phpinfo() per Konfiguraion verboten ist. Unter "Configuration" und "apache3handler" sollte es ein Abschnitt "Loaded Modules" geben und dort müssen Module mit "proxy" im Namen auftauchen. Dann sollte es eigentlich mit Rewrite und dem Apacheproxy funktionieren.

BTW: In meinen Kodeschnippsel oben muss es natürlich www.neu.de heißen. Mein Fehler.

Da war ich mit dem REMs ja schon fast auf den richtigen Weg. Gerne benutzt wird auch "Bis zu 200% schneller als die Vorgängerversion". Da ist dann eine Funktion deutlich schneller und in einen normalen Programm machen die 200% dann 0,1% aus, weil die Funktion nur wenig genutzt wird. Aber es ist schneller!!!
cms, 26. 02. 2015, 12:30 Link
Vielen Dank für die vielen Hinweise.

Wenn ich schrieb, dass TLS sinnlos ist, so meinte ich das nur in Bezug auf die Inhalte von E-Mails.

TLS ist für die Verschlüsselung von Daten, die möglichst nur einmalig zwischen zwei direkt miteinander kommunizierenden Servern hin- und herlaufen, brauchbar, aber nicht wirklich für die Verschlüsselung von E-Mail-Inhalten. Den Grund hierfür haben wir ja schon mehrfach genannt (Zwischenspeicherung der E-Mail im Klartext auf jedem E-Mail-Server).

Ich ging immer davon aus, dass die Verschlüsselung (theoretisch) perfekt gemacht wurde. Es mag schon sein, dass eine schlechte Verschlüsselung mit längeren Schlüsseln nicht so sicher ist wie eine gute Verschlüsselung mit kurzen Schlüsseln.

Die kurze Bitlänge der Schlüsseln bei TLS führen aber dazu, dass die Daten relativ "schnell" und "einfach" zu knacken sind. Wer immer wieder das gleiche Passwort verwendet, um sich irgendwo einzuloggen, versteht vielleicht eher, was ich meine. Die Zugangsdaten sind hier nicht wirklich sicher und sollten normalerweise nach jedem Zugriff ungültig werden. Bei langen Schlüssellängen ist das (rein theoretisch) anders; die Verschlüsselungs kriegt man auch in absehbarer Zeit mit den schnellsten Rechnenanlagen kaum auf.

POP3S ist NICHT für das Verschlüsseln / Entschlüsseln von E-Mail-Inhalten oder auch verschlüsselten Anhängen zu gebrauchen, weil hierbei eine Verletzung der Systemarchitektur / Layer / Schichten stattfinden würde. Die Aufgabe von POP3S ist es, sämtliche Daten, welche von einem Anwendungsprogramm nach außen gehen sollen, zu verschlüsseln, bzw. sämtliche Daten, welche zum Anwendungsprogramm weitergereicht werden sollen, vorher zu entschlüsseln. POP3S realisiert damit die Verschlüsselungsschicht (TLS). GnuPG aber verschlüsselt die Inhalte noch vor dem Anwendungsprotokoll, hier z. B. Hermes oder POP3 bzw. POP3S, sitzt in der Schicht also noch eins drüber, nicht danach.
Isip, 06. 03. 2015, 17:11 Link
Messenger (Pro) oder Pluto legen die zu senden Mails in einen Verzeichnis ab, POPStar, Hermes oder SMTPS nehmen diese Mails und übertragen sie zum Mailserver. Die Mails in diesen Verzeichnis liegen meines Wissen im Rohformat vor, also so wie sie dann über das Internet bis zum Empfänger übertragen werden. Einige Einträge im Header auf dem Weg mal außen vor. SMTPS könnte den Empfänger herausfinden und GnuPG befragen ob die Empfängermail bekannt ist. Wenn diese bekannt ist, kann die Mail mit GnuPG verschlüsselt werden. Dabei kann der Verschlüsselte Text auch als Anhang erstellt werden.

Damit hätte man zwei Fliegen mit einer Klappe erschlagen. Einerseits wird die Verschlüsselung automatisiert und auf der anderen Seite wird die Verschlüsselung nicht Inline, sondern als Anhang versendet.

Auf der anderen Seite holt POP3S die Mails an und legt sie in eine Verzeichnis ab, die dann von Messenger (Pro) oder Pluto geholt werden. POP3S könnte die Mails nach Verschlüsselung prüfen und diese dann via GnuPG entschlüsseln. Dabei sollte auch das Problem mit den verschlüsselten Anhängen bei Messenger Pro ein Ende haben.

Der Nachteil ist, dass die Mails dann unverschlüsselt in Messenger oder Pluto gespeichert sind. Aber das viel größere Problem ist die Einrichtung und dann muss man die eigenen Schlüssel generieren und die Schlüssel der Partner einsammen, prüfen und in GnuPG einfügen.

Das ist alles viel zu umständlich, Eine neue andere Lösung muss her.
cms, 06. 03. 2015, 19:10 Link
Danke für den Hinweis und die Idee.

Grundsätzlich arbeitet meine Software über zwei Schichten: eigentlich werden nur die beiden Protokolle POP3 bzw. SMTP damit realisiert (wie bei !POPStar), allerdings noch eine zusätzliche Schicht unter diese beiden Protokolle geschoben (die sogenannte Verschlüsselungsschicht oder engl. TLS mit eigenem Protokoll). Das war Ziel meiner Bachelorarbeit an der Hochschule Landshut und wurde - entgegen den Bedenken meiner betreuenden Professorin - auch erreicht.

Es spricht grundsätzlich nichts dagegen, auf der anderen Seite, nämlich über POP3 bzw. SMTP noch eine zusätzliche Software eingreifen zu lassen, welche die Dateninhalte auf wirklich harte Verschlüsselung prüft und die Inhalte ggf. automatisch ver- bzw. entschlüsselt. Aber eigentlich sollte das ein PlugIn für das verwendete E-Mail-Programm machen. Die frei verfügbare C-Bibliothek GnuTLS ist für diese heftige Art von Verschlüsselung leider nicht zu gebrauchen, weil sie keine entsprechend lange Schlüsselung kann. GnuTLS ist außerdem nur in Verbindung mit einer Tunnelung zu gebrauchen; d. h. dass der laufende Datenverkehr zwischen zwei miteinander kommunizierenden Rechnern ver- und entschlüsselt wird. Bei E-Mails handelt es sich aber um ein nicht echtzeitfähiges System, d. h. die Daten werden nicht direkt vom Sender zum Empfänger geschickt, sondern _zeitversetzt_ (das bedeutet, der Empfänger holt die Daten irgendwann aus seinem Postfach ab), weshalb hier aber eine Tunnelung bei den zu übertragenden Inhalten nicht mehr greift (die Daten liegen ja in Klartext auf dem Zwischenspeicher vor). Die Verschlüsselung mittels TLS (Tunnelung) dient hier nur für jene Anweisungen, die zum nächsten Rechner gehen (das POP3 bzw. SMTP-Protokoll).

Leider ist es so, dass zumindest mit !MessengerPro zwar die Verwendung von !GnuPG möglich ist, es aber an vielen Stellen nicht reibungslos funktioniert. Hier müsste unbedingt nachgebessert werden. Wahrscheinlich ist die Zahl der Leute, welche !MessengerPro in Verbindung mit !GnuPG verwenden, viel zu gering und liegt weltweit vielleicht nur bei 2 oder 3 Leuten. Zumal der Hersteller nur beschränkte Kapaziten hat. Ich finde es ohnehin schon unglaublich, dass sie einen neuen Computer realisiert haben.

Mein vorrangiges Ziel ist das aber momentan nicht. Momentan versuche ich mir die Multitasking-Programmierung unter RISC OS beizubringen, damit ich meine Software grundsätzlich erst einmal verbessern kann, d. h. sie soll bedienungsfreundlicher werden. Da ich kaum, d. h. keinen entsprechenden Programmierkurs für C + OSLib unter RISC OS gefunden habe, darf ich mir den momentan auch noch schreiben (weshalb die Arbeiten jetzt dementsprechend länger / lange dauern - aber dafür ist dann hoffentlich was da). Das nächste, was noch ansteht, das ist, ein neues Sicherheitsmodul für RISC OS zu schreiben, welches das alte von rcomp ersetzt (hierzu darf ich mir aber leider auch noch viel beibringen). Ich tue, was ich kann, aber in absehbarer Zeit wird das nichts. Auch, weil ich beruflich momentan schon ca. 70 - 80 h die Woche arbeite. Das war letztes Jahr leichter, weil ich nach dem Studienabschluss ca. 5 Monate arbeitslos war.

Den 4. Teil des Programmierkurses habe ich für gut befunden und dir das heute per E-Mail mitgeteilt.
Isip ay Sustansya, 07. 03. 2015, 15:47 Link
ArcSite   News   Magazin   Börse   Links   ArcArchie   Homepages