Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Dumme Frage zum Server Identy Check - RFC 2595
17 views
Skip to first unread message
Alexander Ausserstorfer
Apr 4, 2013, 11:10:30 AM4/4/13
to
Using TLS with IMAP, POP3 and ACAP
http://www.ietf.org/rfc/rfc2595.txt
Auf Seite 2 steht da:
| 2.4. Server Identity Check
|
| During the TLS negotiation, the client MUST check its understanding
| of the server hostname against the server's identity as presented in
| the server Certificate message, in order to prevent man-in-the-middle
| attacks. Matching is performed according to these rules:
|
| - The client MUST use the server hostname it used to open the
| connection as the value to compare against the server name as
| expressed in the server certificate. The client MUST NOT use any
| form of the server hostname derived from an insecure remote source
| (e.g., insecure DNS lookup). CNAME canonicalization is not done.
Warum funktioniert das? Könnte man dem Client denn nicht einfach
_irgendein_ digitales Zertifikat unterschieben, wo aber der entsprechend
richtige Hostname drinsteht?
A.
http://www.ietf.org/rfc/rfc2595.txt
Auf Seite 2 steht da:
| 2.4. Server Identity Check
|
| During the TLS negotiation, the client MUST check its understanding
| of the server hostname against the server's identity as presented in
| the server Certificate message, in order to prevent man-in-the-middle
| attacks. Matching is performed according to these rules:
|
| - The client MUST use the server hostname it used to open the
| connection as the value to compare against the server name as
| expressed in the server certificate. The client MUST NOT use any
| form of the server hostname derived from an insecure remote source
| (e.g., insecure DNS lookup). CNAME canonicalization is not done.
Warum funktioniert das? Könnte man dem Client denn nicht einfach
_irgendein_ digitales Zertifikat unterschieben, wo aber der entsprechend
richtige Hostname drinsteht?
A.
Arno Garrels
Apr 4, 2013, 11:49:47 AM4/4/13
to
von einer vertrauenswürdigen CA ergaunertes Zertifikat. Ersteres
würde i.d.R. als nicht vertrauenswürdig vom Client zurückgewiesen.
Letzteres fliegt i.d.R. schnell auf und so ein Zertifikat wird dann
von der CA zurückgezogen und in die CRL eingetragen, welche natürlich
vom Client bei der Prüfung des Zertifikats Berücksichtigung finden
sollte (viele Wald- und Wiesenanwendungen tun das leider nicht).
--
Arno
Juergen P. Meier
Apr 4, 2013, 11:52:29 PM4/4/13
to
Alexander Ausserstorfer <bavari...@chiemgau-net.de>:
angesehenen vorinstallierten CAs signiert sein.
> Warum funktioniert das? Könnte man dem Client denn nicht einfach
> _irgendein_ digitales Zertifikat unterschieben, wo aber der entsprechend
> richtige Hostname drinsteht?
Es muss von einer der vielen "Vertrauenswuerdigen" bzw. als solche
> _irgendein_ digitales Zertifikat unterschieben, wo aber der entsprechend
> richtige Hostname drinsteht?
angesehenen vorinstallierten CAs signiert sein.
Alexander Ausserstorfer
Apr 6, 2013, 9:06:52 AM4/6/13
to
In message <kjk7b1$frh$1...@online.de>
"Arno Garrels" <vornam...@nospam-gmx.de> wrote:
[TLS in Verbindung mit POP]
>> Warum funktioniert das? Könnte man dem Client denn nicht einfach
>> _irgendein_ digitales Zertifikat unterschieben, wo aber der
>> entsprechend richtige Hostname drinsteht?
>
> Schon, das wäre dann aber vermutlich ein selbstsigniertes oder ein
> von einer vertrauenswürdigen CA ergaunertes Zertifikat. Ersteres
> würde i.d.R. als nicht vertrauenswürdig vom Client zurückgewiesen.
> Letzteres fliegt i.d.R. schnell auf und so ein Zertifikat wird dann
> von der CA zurückgezogen und in die CRL eingetragen, welche natürlich
> vom Client bei der Prüfung des Zertifikats Berücksichtigung finden
> sollte (viele Wald- und Wiesenanwendungen tun das leider nicht).
Was mich momentan beschäftigt, das ist TLS in Verbindung mit POP: Bei
Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername und
Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
verstehe, benötigt man zur Überprüfung des vom Server geschickten
Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
bekommt man dieses? Oder überprüft Thunderbird das Zertifikat gar nicht?
A.
"Arno Garrels" <vornam...@nospam-gmx.de> wrote:
[TLS in Verbindung mit POP]
>> Warum funktioniert das? Könnte man dem Client denn nicht einfach
>> _irgendein_ digitales Zertifikat unterschieben, wo aber der
>> entsprechend richtige Hostname drinsteht?
>
> Schon, das wäre dann aber vermutlich ein selbstsigniertes oder ein
> von einer vertrauenswürdigen CA ergaunertes Zertifikat. Ersteres
> würde i.d.R. als nicht vertrauenswürdig vom Client zurückgewiesen.
> Letzteres fliegt i.d.R. schnell auf und so ein Zertifikat wird dann
> von der CA zurückgezogen und in die CRL eingetragen, welche natürlich
> vom Client bei der Prüfung des Zertifikats Berücksichtigung finden
> sollte (viele Wald- und Wiesenanwendungen tun das leider nicht).
Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername und
Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
verstehe, benötigt man zur Überprüfung des vom Server geschickten
Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
bekommt man dieses? Oder überprüft Thunderbird das Zertifikat gar nicht?
A.
Arno Garrels
Apr 6, 2013, 11:02:19 AM4/6/13
to
Alexander Ausserstorfer wrote:
> Was mich momentan beschäftigt, das ist TLS in Verbindung mit POP: Bei
> Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername
> und Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
> verstehe, benötigt man zur Überprüfung des vom Server geschickten
> Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
> bekommt man dieses?
Sollte das Wurzelzertifikat des POP3-Servers nicht in Thunderbirds
> Was mich momentan beschäftigt, das ist TLS in Verbindung mit POP: Bei
> Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername
> und Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
> verstehe, benötigt man zur Überprüfung des vom Server geschickten
> Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
> bekommt man dieses?
Speicher der vertrauenwürdigen Zertifizierungsstellen sein, kann man
es dort importieren oder man erstellt eine Sicherheits-Ausnahme.
Manchmal schickt der Server die vollständige Kette der Zertifikate,
falls nicht, sollte man die auf der Webseite des Betreibers des
POP3-Server bekommen.
--
Arno
Arno Welzel
Apr 7, 2013, 9:17:47 AM4/7/13
to
Alexander Ausserstorfer, 2013-04-06 15:06:
> In message <kjk7b1$frh$1...@online.de>
> "Arno Garrels" <vornam...@nospam-gmx.de> wrote:
>
> [TLS in Verbindung mit POP]
>
>>> Warum funktioniert das? K�nnte man dem Client denn nicht einfach
>> von einer vertrauensw�rdigen CA ergaunertes Zertifikat. Ersteres
>> w�rde i.d.R. als nicht vertrauensw�rdig vom Client zur�ckgewiesen.
>> vom Client bei der Pr�fung des Zertifikats Ber�cksichtigung finden
Siehe Extras - Einstellungen - Zertifikate.
Da stehen auch die Zertifikate der als vertrauensw�rdig betrachteten
Zertifizierungsstellen drin: Knopf "Zertifikate" und dann Registerkarte
"Zertifizierungsstellen".
Da verh�lt sich Thunderbird nicht anders als Firefox.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
> In message <kjk7b1$frh$1...@online.de>
> "Arno Garrels" <vornam...@nospam-gmx.de> wrote:
>
> [TLS in Verbindung mit POP]
>
>>> _irgendein_ digitales Zertifikat unterschieben, wo aber der
>>> entsprechend richtige Hostname drinsteht?
>>
>> Schon, das w�re dann aber vermutlich ein selbstsigniertes oder ein
>>> entsprechend richtige Hostname drinsteht?
>>
>> von einer vertrauensw�rdigen CA ergaunertes Zertifikat. Ersteres
>> w�rde i.d.R. als nicht vertrauensw�rdig vom Client zur�ckgewiesen.
>> Letzteres fliegt i.d.R. schnell auf und so ein Zertifikat wird dann
>> von der CA zur�ckgezogen und in die CRL eingetragen, welche nat�rlich
>> vom Client bei der Pr�fung des Zertifikats Ber�cksichtigung finden
>> sollte (viele Wald- und Wiesenanwendungen tun das leider nicht).
>
> Was mich momentan besch�ftigt, das ist TLS in Verbindung mit POP: Bei
>
> Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername und
> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
> verstehe, ben�tigt man zur �berpr�fung des vom Server geschickten
> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
> Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
> bekommt man dieses? Oder �berpr�ft Thunderbird das Zertifikat gar nicht?
Siehe Extras - Einstellungen - Zertifikate.
Da stehen auch die Zertifikate der als vertrauensw�rdig betrachteten
Zertifizierungsstellen drin: Knopf "Zertifikate" und dann Registerkarte
"Zertifizierungsstellen".
Da verh�lt sich Thunderbird nicht anders als Firefox.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
Streuner
Apr 25, 2013, 12:03:49 PM4/25/13
to
Am 07.04.2013 15:17, schrieb Arno Welzel:
>> Was mich momentan beschäftigt, das ist TLS in Verbindung mit POP: Bei
OK, diese Programme bringen bereits eine Liste mit den Zertifikaten von
Zertifizierungsstellen mit (wäre das nicht eine Sache des
Betriebssystems?). In RFC 2595 hatte ich das nicht so verstanden, dass
das vom Server geschickte Zertifikat anhand dieser Ausstellerzertifikate
überprüft werden muss.
Momentan versuche ich die Überprüfung eines Zertifikats in einem eigenen
Programm (C) zu realisieren. Genutzt wird GnuTLS in Verbindung mit GCC
unter Cygwin (ich habe es noch nicht geschafft, Unix / Linux nativ auf
meiner Maschine zu installieren).
Im konkreten Fall rufe ich die Funktion
gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,
GNUTLS_X509_FMT_PEM)
auf. CAFILE wurde zuvor mit dem Dateinamen der Zertifikatsliste
definiert (#define CAFILE "...").
Woher bekomme ich nun eine geeignete Zertifizierungsliste oder die
geeigneten Zertifikate in entsprechender Form zur Überprüfung eines vom
Server geschickten Zertifikats?
Wenn ich das Beispiel des X.509-Zertifikats unter
http://de.wikipedia.org/wiki/X.509
in eine Datei kopiere und dann versuche, diese mit obiger Funktion zu
laden, gibt diese den Wert 0 zurück. Das bedeutet wohl an Hand der
Dokumentation unter
http://www.gnutls.org/manual/gnutls.pdf
dass dieses Zertifikat nicht verarbeitet worden ist. Müsste da nicht
eine 1 zurückgeliefert werden (Anzahl der verarbeiteten Zertifikate)?
Ich habe auch versucht, ein Wurzel-Zertifikat der Deutschen Telekom
unter http://www.telesec.de/downloads/DT-Root-CA-1.cer mittels vorher
genannter Funktion zu verarbeiten - aber hier gibt es gleich ein
"Segmentation fault". Mir fällt auf, dass das genannte Zertifikat der
Deutschen Telekom in der Form erheblich von dem Beispiel in Wikipedia
abweicht. Was läuft hier falsch?
S.
>> Was mich momentan beschäftigt, das ist TLS in Verbindung mit POP: Bei
>> Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername und
>> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
>> verstehe, benötigt man zur Überprüfung des vom Server geschickten
>> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
>> Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
>> bekommt man dieses? Oder überprüft Thunderbird das Zertifikat gar nicht?
>
> Siehe Extras - Einstellungen - Zertifikate.
>
> Da stehen auch die Zertifikate der als vertrauenswürdig betrachteten
> Siehe Extras - Einstellungen - Zertifikate.
>
> Zertifizierungsstellen drin: Knopf "Zertifikate" und dann Registerkarte
> "Zertifizierungsstellen".
>
> Da verhält sich Thunderbird nicht anders als Firefox.
> "Zertifizierungsstellen".
>
OK, diese Programme bringen bereits eine Liste mit den Zertifikaten von
Zertifizierungsstellen mit (wäre das nicht eine Sache des
Betriebssystems?). In RFC 2595 hatte ich das nicht so verstanden, dass
das vom Server geschickte Zertifikat anhand dieser Ausstellerzertifikate
überprüft werden muss.
Momentan versuche ich die Überprüfung eines Zertifikats in einem eigenen
Programm (C) zu realisieren. Genutzt wird GnuTLS in Verbindung mit GCC
unter Cygwin (ich habe es noch nicht geschafft, Unix / Linux nativ auf
meiner Maschine zu installieren).
Im konkreten Fall rufe ich die Funktion
gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,
GNUTLS_X509_FMT_PEM)
auf. CAFILE wurde zuvor mit dem Dateinamen der Zertifikatsliste
definiert (#define CAFILE "...").
Woher bekomme ich nun eine geeignete Zertifizierungsliste oder die
geeigneten Zertifikate in entsprechender Form zur Überprüfung eines vom
Server geschickten Zertifikats?
Wenn ich das Beispiel des X.509-Zertifikats unter
http://de.wikipedia.org/wiki/X.509
in eine Datei kopiere und dann versuche, diese mit obiger Funktion zu
laden, gibt diese den Wert 0 zurück. Das bedeutet wohl an Hand der
Dokumentation unter
http://www.gnutls.org/manual/gnutls.pdf
dass dieses Zertifikat nicht verarbeitet worden ist. Müsste da nicht
eine 1 zurückgeliefert werden (Anzahl der verarbeiteten Zertifikate)?
Ich habe auch versucht, ein Wurzel-Zertifikat der Deutschen Telekom
unter http://www.telesec.de/downloads/DT-Root-CA-1.cer mittels vorher
genannter Funktion zu verarbeiten - aber hier gibt es gleich ein
"Segmentation fault". Mir fällt auf, dass das genannte Zertifikat der
Deutschen Telekom in der Form erheblich von dem Beispiel in Wikipedia
abweicht. Was läuft hier falsch?
S.
Arno Welzel
Apr 29, 2013, 5:51:16 AM4/29/13
to
Am 25.04.2013 18:03, schrieb Streuner:
> Am 07.04.2013 15:17, schrieb Arno Welzel:
>
>>> Was mich momentan besch�ftigt, das ist TLS in Verbindung mit POP: Bei
> Am 07.04.2013 15:17, schrieb Arno Welzel:
>
>>> Thunderbird z. B. kann man TLS verwenden, hat aber nur Benutzername und
>>> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
>>> verstehe, ben�tigt man zur �berpr�fung des vom Server geschickten
>>> Passwort des zugeordneten Kontos einzugeben. So wie ich das jetzt
>>> Zertifikats jedoch das Zertifikat der Zertifizierungsstelle. Woher
>>> bekommt man dieses? Oder �berpr�ft Thunderbird das Zertifikat gar nicht?
>>
>> Siehe Extras - Einstellungen - Zertifikate.
>>
>> Da stehen auch die Zertifikate der als vertrauensw�rdig betrachteten
>> Siehe Extras - Einstellungen - Zertifikate.
>>
>> Zertifizierungsstellen drin: Knopf "Zertifikate" und dann Registerkarte
>> "Zertifizierungsstellen".
>>
>> Da verh�lt sich Thunderbird nicht anders als Firefox.
>> "Zertifizierungsstellen".
>>
>
> OK, diese Programme bringen bereits eine Liste mit den Zertifikaten von
> Zertifizierungsstellen mit (w�re das nicht eine Sache des
> OK, diese Programme bringen bereits eine Liste mit den Zertifikaten von
> Betriebssystems?). In RFC 2595 hatte ich das nicht so verstanden, dass
> das vom Server geschickte Zertifikat anhand dieser Ausstellerzertifikate
> �berpr�ft werden muss.
> das vom Server geschickte Zertifikat anhand dieser Ausstellerzertifikate
Es w�re zumindest ungew�hnlich, wenn man ein TLS-Zertifikat ohne g�ltige
Signatur akzeptieren w�rde - und die Signatur erfolgt �blicherweise von
einer CA, der man vertraut. Der Sinn von TLS ist ja nicht nur, die
Verbindung zu verschl�sseln, sondern auch die Authenzit�t der
Gegenstelle �berpr�fen zu k�nnen.
Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
> Momentan versuche ich die �berpr�fung eines Zertifikats in einem eigenen
> Programm (C) zu realisieren. Genutzt wird GnuTLS in Verbindung mit GCC
> unter Cygwin (ich habe es noch nicht geschafft, Unix / Linux nativ auf
> meiner Maschine zu installieren).
>
> Im konkreten Fall rufe ich die Funktion
>
> gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,
> GNUTLS_X509_FMT_PEM)
>
> auf. CAFILE wurde zuvor mit dem Dateinamen der Zertifikatsliste
> definiert (#define CAFILE "...").
>
> Woher bekomme ich nun eine geeignete Zertifizierungsliste oder die
> geeigneten Zertifikate in entsprechender Form zur �berpr�fung eines vom
> unter Cygwin (ich habe es noch nicht geschafft, Unix / Linux nativ auf
> meiner Maschine zu installieren).
>
> Im konkreten Fall rufe ich die Funktion
>
> gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,
> GNUTLS_X509_FMT_PEM)
>
> auf. CAFILE wurde zuvor mit dem Dateinamen der Zertifikatsliste
> definiert (#define CAFILE "...").
>
> Woher bekomme ich nun eine geeignete Zertifizierungsliste oder die
> Server geschickten Zertifikats?
Von der CA, die das Zertifikat des Servers ausgestellt hat.
> Wenn ich das Beispiel des X.509-Zertifikats unter
>
> http://de.wikipedia.org/wiki/X.509
>
> in eine Datei kopiere und dann versuche, diese mit obiger Funktion zu
> Dokumentation unter
>
> http://www.gnutls.org/manual/gnutls.pdf
>
> dass dieses Zertifikat nicht verarbeitet worden ist. M�sste da nicht
> eine 1 zur�ckgeliefert werden (Anzahl der verarbeiteten Zertifikate)?
>
> Ich habe auch versucht, ein Wurzel-Zertifikat der Deutschen Telekom
> unter http://www.telesec.de/downloads/DT-Root-CA-1.cer mittels vorher
> genannter Funktion zu verarbeiten - aber hier gibt es gleich ein
> "Segmentation fault". Mir f�llt auf, dass das genannte Zertifikat der
> Ich habe auch versucht, ein Wurzel-Zertifikat der Deutschen Telekom
> unter http://www.telesec.de/downloads/DT-Root-CA-1.cer mittels vorher
> genannter Funktion zu verarbeiten - aber hier gibt es gleich ein
> Deutschen Telekom in der Form erheblich von dem Beispiel in Wikipedia
> abweicht. Was l�uft hier falsch?
Du musst das Format des Zertifikats eventuell noch umwandeln.
Siehe auch hier:
<https://www.sslshopper.com/ssl-converter.html>
Helmut Springer
Apr 29, 2013, 5:57:21 AM4/29/13
to
Streuner <ute...@yahoo.de> wrote:
> In RFC 2595 hatte ich das nicht so verstanden, dass das vom Server
> geschickte Zertifikat anhand dieser Ausstellerzertifikate
> ï¿œberprï¿œft werden muss.
> In RFC 2595 hatte ich das nicht so verstanden, dass das vom Server
> geschickte Zertifikat anhand dieser Ausstellerzertifikate
2.5. TLS Security Policy Check
Both the client and server MUST check the result of the
STARTTLS command and subsequent TLS negotiation to see whether
acceptable authentication or privacy was achieved. Ignoring
this step completely invalidates using TLS for security. The
decision about whether acceptable authentication or privacy was
achieved is made locally, is implementation-dependent, and is
beyond the scope of this document.
--
Best regards
helmut springer panta rhei
Michael Mendelsohn
Apr 30, 2013, 3:00:08 PM4/30/13
to
Am 29.04.2013 11:51, schrieb Arno Welzel:
> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
Eventuell gibt es daf�r auch Sicherheitsgr�nde?
> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
mein Emailprogramm das dann auch akzeptiert.
Viele Gr��e
--mendel
--
"Michael" ist kein Name, sondern eine Bev�lkerungsgruppe.
http://fiff.de/ Forum InformatikerInnen f�r Frieden und
gesellschaftliche Verantwortung e.V.
Stefan Kanthak
Apr 30, 2013, 4:10:43 PM4/30/13
to
"Michael Mendelsohn" <fern...@news.mendelsohn.de> schrieb:
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
>> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
>> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
>
> Eventuell gibt es daf�r auch Sicherheitsgr�nde?
> Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
> selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
> mein Emailprogramm das dann auch akzeptiert.
1. kann jedes Programm im Zertifikatsspeicher des Systems (der ohnehin
einen system-weiten und einen benutzer-spezifischen Teil hat) seinen
eigenen "Container" verwalten.
2. koennte der Zertifikatsspeicher des Systems eine Funktion anbieten,
mit der jedem Programm nur die Nutzung von explizit (vom Benutzer
und/oder dem Administrator) fuer dieses Programm erlaubten
Zertifikaten ermoeglicht wird.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �823
Abs. 1 sowie �1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
>> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
>> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
>
> Eventuell gibt es daf�r auch Sicherheitsgr�nde?
> Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
> selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
> mein Emailprogramm das dann auch akzeptiert.
einen system-weiten und einen benutzer-spezifischen Teil hat) seinen
eigenen "Container" verwalten.
2. koennte der Zertifikatsspeicher des Systems eine Funktion anbieten,
mit der jedem Programm nur die Nutzung von explizit (vom Benutzer
und/oder dem Administrator) fuer dieses Programm erlaubten
Zertifikaten ermoeglicht wird.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �823
Abs. 1 sowie �1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Arno Welzel
May 1, 2013, 5:52:46 PM5/1/13
to
Michael Mendelsohn, 2013-04-30 21:00:
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
>> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
>> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
>
> Eventuell gibt es daf�r auch Sicherheitsgr�nde?
> Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
> selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
> mein Emailprogramm das dann auch akzeptiert.
Ich kann mir gerade keine Situation vorstellen, wo ich dem Zertifikat
f�r eine Domain zwar f�r den Zugriff auf die Website traue, aber nicht
f�r den Abruf oder das Versenden von E-Mail.
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> daf�r nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
>> wollte, f�r jedes OS eine separate Implementierung zu bauen zus�tzlich
>> eine eigene L�sung f�r den Fall, dass das nicht m�glich ist.
>
> Eventuell gibt es daf�r auch Sicherheitsgr�nde?
> Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
> selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
> mein Emailprogramm das dann auch akzeptiert.
f�r eine Domain zwar f�r den Zugriff auf die Website traue, aber nicht
f�r den Abruf oder das Versenden von E-Mail.
Message has been deleted
Stefan Kanthak
May 1, 2013, 7:11:45 PM5/1/13
to
"Heiko Schlenker" <hsc...@gmx.de> schrieb:
> * Arno Welzel <use...@arnowelzel.de> schrieb:
>> f�ｿｽr den Abruf oder das Versenden von E-Mail.
>
> Es sind verschiedene Dienste. X.509-Erweiterungen wie 'netscape
> certificate type' erlauben, die Anwendungen f�ｿｽr ein Zertifikat zu
> spezifizieren: <http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html>
AUTSCH!
In beiden Faellen dient das X.509-Zertifikat zur Authentifizierung eines
Servers (und das ist unabhaengig von Protokollen wie SMTPS oder HTTPS
oder POP3S oder IMAPS resp. der Anwendung alias Programm).
Du verwechselst gerade Server-Authentifizierung mit Mail-Verschluesselung
oder -Signierung, bzw. Verwendungszweck mit Anwendung/Programm.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �ｿｽ823
Abs. 1 sowie �ｿｽ1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
> * Arno Welzel <use...@arnowelzel.de> schrieb:
>> Michael Mendelsohn, 2013-04-30 21:00:
>>> Mir w�ｿｽre zum beispiel nicht klar, das ich, wenn ich beim Browsen einem
>>> selbsteingestellten Zertifikat vertraue, dies dann auch bedeutet, dass
>>> mein Emailprogramm das dann auch akzeptiert.
>>
>> Ich kann mir gerade keine Situation vorstellen, wo ich dem Zertifikat
>> f�ｿｽr eine Domain zwar f�ｿｽr den Zugriff auf die Website traue, aber nicht
>>> mein Emailprogramm das dann auch akzeptiert.
>>
>> Ich kann mir gerade keine Situation vorstellen, wo ich dem Zertifikat
>> f�ｿｽr den Abruf oder das Versenden von E-Mail.
>
> Es sind verschiedene Dienste. X.509-Erweiterungen wie 'netscape
> certificate type' erlauben, die Anwendungen f�ｿｽr ein Zertifikat zu
> spezifizieren: <http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html>
AUTSCH!
In beiden Faellen dient das X.509-Zertifikat zur Authentifizierung eines
Servers (und das ist unabhaengig von Protokollen wie SMTPS oder HTTPS
oder POP3S oder IMAPS resp. der Anwendung alias Programm).
Du verwechselst gerade Server-Authentifizierung mit Mail-Verschluesselung
oder -Signierung, bzw. Verwendungszweck mit Anwendung/Programm.
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �ｿｽ823
Abs. 1 sowie �ｿｽ1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Message has been deleted
Helmut Springer
May 2, 2013, 4:00:33 AM5/2/13
to
Arno Welzel <use...@arnowelzel.de> wrote:
>> Mir wï¿œre zum beispiel nicht klar, das ich, wenn ich beim Browsen
> traue, aber nicht fï¿œr den Abruf oder das Versenden von E-Mail.
Ich schon: wenn die Vertraulichkeit der Websitedaten geringer als
die der EMail ist. Was sie bei mir regelmaessig sind.
>> Mir wï¿œre zum beispiel nicht klar, das ich, wenn ich beim Browsen
>> einem selbsteingestellten Zertifikat vertraue, dies dann auch
>> bedeutet, dass mein Emailprogramm das dann auch akzeptiert.
>
> Ich kann mir gerade keine Situation vorstellen, wo ich dem
> Zertifikat fï¿œr eine Domain zwar fï¿œr den Zugriff auf die Website
>> bedeutet, dass mein Emailprogramm das dann auch akzeptiert.
>
> Ich kann mir gerade keine Situation vorstellen, wo ich dem
> traue, aber nicht fï¿œr den Abruf oder das Versenden von E-Mail.
Ich schon: wenn die Vertraulichkeit der Websitedaten geringer als
die der EMail ist. Was sie bei mir regelmaessig sind.
Arno Welzel
May 2, 2013, 11:19:34 AM5/2/13
to
SSL/TLS und SMTP/IMAP/POP3 zugreifst, gleichzeitig aber den Browser
nicht per SSL/TLS und HTTP auf exakt die selbe Domain - wir reden hier
ja ï¿œber *ein* Zertifikat und nicht eines nur fï¿œr den Mailserver und ein
anderes fï¿œr den Webserver.
Also als konstruiertes Beispiel:
Man wï¿œrde dem Zertifikat mit Gï¿œltigkeit fï¿œr *.gmx.net (oder alternativen
Namen fï¿œr die verschiedenen Hosts) nur fï¿œr den Zugriff via SSL/TLS auf
mail.gmx.net, pop.gmx.net und imap.gmx.net vertrauen, aber fï¿œr Zugriff
per HTTP auf www.gmx.net nicht?
Paul Muster
May 2, 2013, 3:03:01 PM5/2/13
to
On 01.05.2013 23:52, Arno Welzel wrote:
> Ich kann mir gerade keine Situation vorstellen, wo ich dem Zertifikat
> für eine Domain zwar für den Zugriff auf die Website traue, aber nicht
> Ich kann mir gerade keine Situation vorstellen, wo ich dem Zertifikat
> für den Abruf oder das Versenden von E-Mail.
Dafür sehe auch ich keinen Anwendungszweck.
mfG Paul
Paul Muster
May 2, 2013, 3:04:05 PM5/2/13
to
On 30.04.2013 21:00, Michael Mendelsohn wrote:
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> dafür nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
> Am 29.04.2013 11:51, schrieb Arno Welzel:
>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>> wollte, für jedes OS eine separate Implementierung zu bauen zusätzlich
>> eine eigene Lösung für den Fall, dass das nicht möglich ist.
>
> Eventuell gibt es dafür auch Sicherheitsgründe?
Meiner Einschätzung nach eher ein gewisser Machtanspruch, den man mit
Hilfe von Firefox durchsetzt.
mfG Paul
Juergen P. Meier
May 3, 2013, 1:32:07 AM5/3/13
to
Paul Muster <exp-3...@news.muster.de1.cc>:
>>> wollte, fï¿œr jedes OS eine separate Implementierung zu bauen zusï¿œtzlich
>>> eine eigene Lï¿œsung fï¿œr den Fall, dass das nicht mï¿œglich ist.
>>
>> Eventuell gibt es dafï¿œr auch Sicherheitsgrï¿œnde?
>
> Meiner Einschï¿œtzung nach eher ein gewisser Machtanspruch, den man mit
> Hilfe von Firefox durchsetzt.
Anfangs war das reine Notwendigkeit (Netsacpe), weil damals noch keine
Systemstores existierten - und auch heute existiert auf mind. zwei
der haeufigerern Plattformen kein einheitlicher, sinnvoller und
brauchbarer Systemweiter Zertifikatsstore mit stabilen Schnittstellen.
D.h. man muss sowieso einen eigenen Zertifikatsstore pflegen.
Zudem ist der eigene Store fest mit der kranken implementierung
verwoben, so das ein Aufbrechen der dysfunktionen und Workarounds die
Notwendig waeren um eine Schnittestelle der beiden etablierten
Systemstores (von Mickeysoft und Apple) nutzen zu koennen, viel zu
Aufwaendig.
Technisch betrachtet bietet das noch den Vorteil, schnell und selbst
vollstaendig auf Sicherheitsluecken und Fehler mit eigenen
Workarounds (s.O.) reagieren zu koennen, und nicht auf den OS-Hersteller
angewiesen zu sein.
Und letztlich ist es aktuell ein Machtfaktor, um selbst Druck auf die
CA ausueben zu koennen (wirtschaftlich wie politisch). Und diesen
HEbel wird sich Mozilla garantiert nicht so einfach aus der Hand
nehmen lassen.
> On 30.04.2013 21:00, Michael Mendelsohn wrote:
>> Am 29.04.2013 11:51, schrieb Arno Welzel:
>
>>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>>> dafï¿œr nutzen, liegt wohl daran, dass man sich nicht den Aufwand antun
>> Am 29.04.2013 11:51, schrieb Arno Welzel:
>
>>> Dass Thunderbird und Firfox nicht den Zertifikatsspeicher des Systems
>>> wollte, fï¿œr jedes OS eine separate Implementierung zu bauen zusï¿œtzlich
>>> eine eigene Lï¿œsung fï¿œr den Fall, dass das nicht mï¿œglich ist.
>>
>> Eventuell gibt es dafï¿œr auch Sicherheitsgrï¿œnde?
>
> Meiner Einschï¿œtzung nach eher ein gewisser Machtanspruch, den man mit
> Hilfe von Firefox durchsetzt.
Anfangs war das reine Notwendigkeit (Netsacpe), weil damals noch keine
Systemstores existierten - und auch heute existiert auf mind. zwei
der haeufigerern Plattformen kein einheitlicher, sinnvoller und
brauchbarer Systemweiter Zertifikatsstore mit stabilen Schnittstellen.
D.h. man muss sowieso einen eigenen Zertifikatsstore pflegen.
Zudem ist der eigene Store fest mit der kranken implementierung
verwoben, so das ein Aufbrechen der dysfunktionen und Workarounds die
Notwendig waeren um eine Schnittestelle der beiden etablierten
Systemstores (von Mickeysoft und Apple) nutzen zu koennen, viel zu
Aufwaendig.
Technisch betrachtet bietet das noch den Vorteil, schnell und selbst
vollstaendig auf Sicherheitsluecken und Fehler mit eigenen
Workarounds (s.O.) reagieren zu koennen, und nicht auf den OS-Hersteller
angewiesen zu sein.
Und letztlich ist es aktuell ein Machtfaktor, um selbst Druck auf die
CA ausueben zu koennen (wirtschaftlich wie politisch). Und diesen
HEbel wird sich Mozilla garantiert nicht so einfach aus der Hand
nehmen lassen.
Message has been deleted
Stefan Kanthak
May 3, 2013, 8:08:16 AM5/3/13
to
>>>>> Mir w�re zum beispiel nicht klar, das ich, wenn ich beim Browsen
>>>> traue, aber nicht f�r den Abruf oder das Versenden von E-Mail.
>> anderes f�r den Webserver.
>
> Sind der Webserver, der Dienste vollgestopft mit aktiven Inhalten
> anbietet, und die Mailserver gleicherma�en vertrauensw�rdig? ;-)
AUTSCH!
Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
kommunizierten Inhalte)!
Stefan
[
--
>>>>> einem selbsteingestellten Zertifikat vertraue, dies dann auch
>>>>> bedeutet, dass mein Emailprogramm das dann auch akzeptiert.
>>>>
>>>> Ich kann mir gerade keine Situation vorstellen, wo ich dem
>>>> Zertifikat f�r eine Domain zwar f�r den Zugriff auf die Website
>>>>> bedeutet, dass mein Emailprogramm das dann auch akzeptiert.
>>>>
>>>> Ich kann mir gerade keine Situation vorstellen, wo ich dem
>>>> traue, aber nicht f�r den Abruf oder das Versenden von E-Mail.
>>>
>>> Ich schon: wenn die Vertraulichkeit der Websitedaten geringer als
>>> die der EMail ist. Was sie bei mir regelmaessig sind.
>>
>> Definiere "Vertraulichkeit" und wieso Du zwar auf einen Mailserver per
>> SSL/TLS und SMTP/IMAP/POP3 zugreifst, gleichzeitig aber den Browser
>> nicht per SSL/TLS und HTTP auf exakt die selbe Domain - wir reden hier
>> ja �ber *ein* Zertifikat und nicht eines nur f�r den Mailserver und ein
>>> Ich schon: wenn die Vertraulichkeit der Websitedaten geringer als
>>> die der EMail ist. Was sie bei mir regelmaessig sind.
>>
>> Definiere "Vertraulichkeit" und wieso Du zwar auf einen Mailserver per
>> SSL/TLS und SMTP/IMAP/POP3 zugreifst, gleichzeitig aber den Browser
>> nicht per SSL/TLS und HTTP auf exakt die selbe Domain - wir reden hier
>> anderes f�r den Webserver.
>
> Sind der Webserver, der Dienste vollgestopft mit aktiven Inhalten
> anbietet, und die Mailserver gleicherma�en vertrauensw�rdig? ;-)
AUTSCH!
Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
kommunizierten Inhalte)!
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen �823
Abs. 1 sowie �1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Message has been deleted
Stefan Kanthak
May 3, 2013, 9:45:29 AM5/3/13
to
"Heiko Schlenker" <hsc...@gmx.de> schrieb:
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>> kommunizierten Inhalte)!
>
> Dem Benutzer ist es ziemlich wurscht, inwiefern Sicherheitsziele nicht
> erreicht werden. Durch geknackte Webserver, durch abgeh�rte Leitungen ...
Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
Uebertragung sicher (Transportverschluesselung).
Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
wie unter <https://www.provider.tlb/example.html>
JFTR: selbiges gilt ebenso fuer die Ende-zu-Ende-Verschluesselung bei
Mail. Eine (egal ob per X.509 oder GPG) verschluesselte Nachricht ist
vertraulich, aber noch lange nicht vertrauenswuerdig.
> Worauf ich hinaus will: Es kann sinnvoll sein, f�r verschiedene
> Anwendungen auch verschiedene Zertifikate zu benutzen. Ein Zertifikat
> f�rs Surfen im WWW, ein Zertikat f�r die Kommunikation mit Mailservern
> usw.
Ein X.509-Zertifikat fuer www.provider.tld ist ungleich dem fuer
smtp.provider.tld ist ungleich dem fuer pop3.provider.tld ist
ungleich dem fuer imap.provider.tld.
> Warum? Weil die Sicherheitsanforderungen an die jeweiligen
> Dienste unterschiedlich sein k�nnen. Das d�rfte sich mit einem
> einzigen Zertifikat nicht abbilden lassen.
Nochmal: s.o.
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>> kommunizierten Inhalte)!
>
> erreicht werden. Durch geknackte Webserver, durch abgeh�rte Leitungen ...
Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
Uebertragung sicher (Transportverschluesselung).
Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
wie unter <https://www.provider.tlb/example.html>
JFTR: selbiges gilt ebenso fuer die Ende-zu-Ende-Verschluesselung bei
Mail. Eine (egal ob per X.509 oder GPG) verschluesselte Nachricht ist
vertraulich, aber noch lange nicht vertrauenswuerdig.
> Worauf ich hinaus will: Es kann sinnvoll sein, f�r verschiedene
> Anwendungen auch verschiedene Zertifikate zu benutzen. Ein Zertifikat
> f�rs Surfen im WWW, ein Zertikat f�r die Kommunikation mit Mailservern
> usw.
Ein X.509-Zertifikat fuer www.provider.tld ist ungleich dem fuer
smtp.provider.tld ist ungleich dem fuer pop3.provider.tld ist
ungleich dem fuer imap.provider.tld.
> Warum? Weil die Sicherheitsanforderungen an die jeweiligen
> Dienste unterschiedlich sein k�nnen. Das d�rfte sich mit einem
> einzigen Zertifikat nicht abbilden lassen.
Nochmal: s.o.
Streuner
May 3, 2013, 1:51:09 PM5/3/13
to
Am 29.04.2013 11:51, schrieb Arno Welzel:
[Zertifikatsprobleme]
> Du musst das Format des Zertifikats eventuell noch umwandeln.
>
> Siehe auch hier:
>
> <https://www.sslshopper.com/ssl-converter.html >
sein, dass es sich bei .pem rein um Base64-codierte .der-Dateien
handelt? Zumindest konnte ich mit Hilfe eines kleinen Programms, das aus
bin�ren Daten E-Mail-Anh�nge zum Verschicken generiert, aus einer
.pem-Datei fast vollst�ndig die .der-Datei erzeugen (beide liegen auf
der Webseite http://www.telesec.de vor).
Gru�,
S.
Message has been deleted
Stefan Kanthak
May 4, 2013, 8:29:10 AM5/4/13
to
"Heiko Schlenker" <hsc...@gmx.de> schrieb:
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> "Heiko Schlenker" <hsc...@gmx.de> schrieb:
>>> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>>>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>>>> kommunizierten Inhalte)!
>>>
>>> Dem Benutzer ist es ziemlich wurscht, inwiefern Sicherheitsziele nicht
>>> erreicht werden. Durch geknackte Webserver, durch abgeh�rte Leitungen ...
>>
>> Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
>> Uebertragung sicher (Transportverschluesselung).
>> Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
>> liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
>> wie unter <https://www.provider.tlb/example.html>
>
> Ist eigentlich wurscht. Die Frage war:
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> "Heiko Schlenker" <hsc...@gmx.de> schrieb:
>>> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>>>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>>>> kommunizierten Inhalte)!
>>>
>>> Dem Benutzer ist es ziemlich wurscht, inwiefern Sicherheitsziele nicht
>>> erreicht werden. Durch geknackte Webserver, durch abgeh�rte Leitungen ...
>>
>> Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
>> Uebertragung sicher (Transportverschluesselung).
>> Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
>> liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
>> wie unter <https://www.provider.tlb/example.html>
>
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>>>> Ich kann mir gerade keine Situation vorstellen, wo ich dem
>>>> Zertifikat f�r eine Domain zwar f�r den Zugriff auf die Website
>>>> traue, aber nicht f�r den Abruf oder das Versenden von E-Mail.
>
> Da lautet die Antwort: Weil ich dem Webserver weniger vertraue als dem
>>>> Ich kann mir gerade keine Situation vorstellen, wo ich dem
>>>> Zertifikat f�r eine Domain zwar f�r den Zugriff auf die Website
>>>> traue, aber nicht f�r den Abruf oder das Versenden von E-Mail.
>
> Mailserver, weil ich dem entfernten E-Mail-Webclient weniger vertraue
> als meinem lokalen Mailclient.
Immer noch falsch^Wnicht richtig!
Du verwechselst gerade "Vertrauen in Zertifikat" mit "Vertrauen in Server".
JFTR: welcher (grosse) Provider verwendet auf "*.provider.tld" ausgestellte
Zertifikate?
Typischerweise existieren getrennte Zertifikate fuer "www.provider.tld",
"mail.provider.tld", "pop3.provider.tld", ...
Arno Welzel
May 6, 2013, 4:30:26 AM5/6/13
to
Am 04.05.2013 04:04, schrieb Heiko Schlenker:
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> "Heiko Schlenker" <hsc...@gmx.de> schrieb:
>>> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>>>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>>>> kommunizierten Inhalte)!
>>>
>>> Dem Benutzer ist es ziemlich wurscht, inwiefern Sicherheitsziele nicht
>>> erreicht werden. Durch geknackte Webserver, durch abgehörte Leitungen ...
> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>> "Heiko Schlenker" <hsc...@gmx.de> schrieb:
>>> * Stefan Kanthak <dont.delete-this.don...@expires-2012-04-30.arcornews.de> schrieb:
>>>> Vertraulichkeit (der Kommunikation) <> Vertrauenswuerdigkeit (der
>>>> kommunizierten Inhalte)!
>>>
>>> Dem Benutzer ist es ziemlich wurscht, inwiefern Sicherheitsziele nicht
>>
>> Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
>> Uebertragung sicher (Transportverschluesselung).
>> Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
>> liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
>> wie unter <https://www.provider.tlb/example.html>
>
>> Nochmal: SSL/TLS stellen (richtig angewendet) die Vertraulichkeit der
>> Uebertragung sicher (Transportverschluesselung).
>> Die uebertragenen Daten sind davon UNABHAENGIG, Web- (und Mail-Server)
>> liefern unter <http://www.provider.tlb/example.html> dieselben Inhalte
>> wie unter <https://www.provider.tlb/example.html>
>
>>>> Ich kann mir gerade keine Situation vorstellen, wo ich dem
>>>> Zertifikat für eine Domain zwar für den Zugriff auf die Website
>>>> traue, aber nicht für den Abruf oder das Versenden von E-Mail.
>
> Da lautet die Antwort: Weil ich dem Webserver weniger vertraue als dem
> Mailserver, weil ich dem entfernten E-Mail-Webclient weniger vertraue
> als meinem lokalen Mailclient.
Du verwechselst immer noch "vertraulich" und "vertrauenswürdig".
> Da lautet die Antwort: Weil ich dem Webserver weniger vertraue als dem
> Mailserver, weil ich dem entfernten E-Mail-Webclient weniger vertraue
> als meinem lokalen Mailclient.
Abgesehen davon finde ich es bemerkenswert, dass jemand dem Betreiber
eines Mailservers vertraut, gleichzeitig aber dessen Website für so
unsicher hält, dass er es für ein Sicherheitsrisiko hält, wenn der
Browser bei einem Zugriff darauf per SSL/TLS nicht vor dem gültigen, und
in anderem Kontext vertrauten Zertifikat warnt.
Michael Mendelsohn
May 9, 2013, 6:43:26 PM5/9/13
to
Am 06.05.2013 10:30, schrieb Arno Welzel:
> Abgesehen davon finde ich es bemerkenswert, dass jemand dem Betreiber
> eines Mailservers vertraut, gleichzeitig aber dessen Website für so
> unsicher hält, dass er es für ein Sicherheitsrisiko hält, wenn der
> Browser bei einem Zugriff darauf per SSL/TLS nicht vor dem gültigen, und
> in anderem Kontext vertrauten Zertifikat warnt.
Hier hast du einen Zirkelschluss. Wenn du dem Betreiber des mailservers
> Abgesehen davon finde ich es bemerkenswert, dass jemand dem Betreiber
> eines Mailservers vertraut, gleichzeitig aber dessen Website für so
> unsicher hält, dass er es für ein Sicherheitsrisiko hält, wenn der
> Browser bei einem Zugriff darauf per SSL/TLS nicht vor dem gültigen, und
> in anderem Kontext vertrauten Zertifikat warnt.
vertraust, brauchst du ja das Zertifkat nicht mehr (jedenfalls nicht dazu).
Der Witz besteht darin, was passiert, wenn dein Mailserver eben eben
nicht vom vermeintlichen Betreiber betrieben wird, sondern vom MitM.
Wenn der Angreifer es erfolgreich geschafft hat, mein DNS anzugreifen,
und mir dann in eine Webseitenanforderung einen https-Zugriff auf
meineemail.de unterjubelt, wo ich das Zertifkat dann "wegklicke", weil
ich bei der Webite, in die er das eingebette hat, auf Sicherheit keinen
Wert lege, und er damit dann den Email-Zugriff auf seinen MitM-Server
ohne weitere Nachfrage über die Bühne bekommt, hätte ich ein Problem,
das ich so in der Form nicht erwarten würde.
Das ist natürlioch alles hypothetisch, und hoffentlich meckert auch das
Email-Programm, wenn der Server sich auf einmal anders idetifiziert,
aber ob das hilft?
Viele Grüße
--mendel
--
"Michael" ist kein Name, sondern eine Bevölkerungsgruppe.
http://fiff.de/ Forum InformatikerInnen für Frieden und
gesellschaftliche Verantwortung e.V.
Juergen P. Meier
May 10, 2013, 1:37:07 AM5/10/13
to
Michael Mendelsohn <fern...@news.mendelsohn.de>:
> Das ist natï¿œrlioch alles hypothetisch, und hoffentlich meckert auch das
Nicht hypothetisch, sondern ganz praktisch.
> Email-Programm, wenn der Server sich auf einmal anders idetifiziert,
Nein, das tut es eben genau nicht.
> aber ob das hilft?
Gegen MitM? Nein.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Das ist natï¿œrlioch alles hypothetisch, und hoffentlich meckert auch das
Nicht hypothetisch, sondern ganz praktisch.
> Email-Programm, wenn der Server sich auf einmal anders idetifiziert,
> aber ob das hilft?
Gegen MitM? Nein.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Arno Welzel
May 15, 2013, 5:24:59 AM5/15/13
to
Am 10.05.2013 00:43, schrieb Michael Mendelsohn:
> Am 06.05.2013 10:30, schrieb Arno Welzel:
>> Abgesehen davon finde ich es bemerkenswert, dass jemand dem Betreiber
>> eines Mailservers vertraut, gleichzeitig aber dessen Website für so
>> unsicher hält, dass er es für ein Sicherheitsrisiko hält, wenn der
>> Browser bei einem Zugriff darauf per SSL/TLS nicht vor dem gültigen, und
>> in anderem Kontext vertrauten Zertifikat warnt.
>
> Hier hast du einen Zirkelschluss. Wenn du dem Betreiber des mailservers
> vertraust, brauchst du ja das Zertifkat nicht mehr (jedenfalls nicht dazu).
Doch - denn ich muss ja sicherstellen, dass ich auch wirklich mit dem
> Am 06.05.2013 10:30, schrieb Arno Welzel:
>> Abgesehen davon finde ich es bemerkenswert, dass jemand dem Betreiber
>> eines Mailservers vertraut, gleichzeitig aber dessen Website für so
>> unsicher hält, dass er es für ein Sicherheitsrisiko hält, wenn der
>> Browser bei einem Zugriff darauf per SSL/TLS nicht vor dem gültigen, und
>> in anderem Kontext vertrauten Zertifikat warnt.
>
> Hier hast du einen Zirkelschluss. Wenn du dem Betreiber des mailservers
> vertraust, brauchst du ja das Zertifkat nicht mehr (jedenfalls nicht dazu).
korrekten Mailserver rede. Und wenn aufgrund des Zertifikats dem
Mailserver vertraut wird, finde ich es halt seltsam, dass man genau dem
selben Zertifikat nicht mehr trauen soll, wenn man sich via HTTP mit dem
selben Anbieter verbindet.
> Der Witz besteht darin, was passiert, wenn dein Mailserver eben eben
> nicht vom vermeintlichen Betreiber betrieben wird, sondern vom MitM.
> Wenn der Angreifer es erfolgreich geschafft hat, mein DNS anzugreifen,
> und mir dann in eine Webseitenanforderung einen https-Zugriff auf
> meineemail.de unterjubelt, wo ich das Zertifkat dann "wegklicke", weil
> ich bei der Webite, in die er das eingebette hat, auf Sicherheit keinen
> Wert lege, und er damit dann den Email-Zugriff auf seinen MitM-Server
> ohne weitere Nachfrage über die Bühne bekommt, hätte ich ein Problem,
> das ich so in der Form nicht erwarten würde.
>
> Das ist natürlioch alles hypothetisch, und hoffentlich meckert auch das
> Email-Programm, wenn der Server sich auf einmal anders idetifiziert,
> aber ob das hilft?
als gültig angesehen wird - also nicht von einer als vertrauenswürdig
angesehenen CA ausgestellt wurde. Allein ein anderes Zertifikat als
bisher ist da noch kein Grund für irgendwelche Meldungen. Das lässt sich
nur dadurch erreichen, dass man *alle* CAs aus den Listen löscht und
*nur* noch einzelne Zertifikate als Ausnahmeregel bestätigt (nachdem man
sich von deren Echtheit überzeugt hat).
0 new messages