[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wie Imap Zugang von Außen über iPhone sicher machen



Am Freitag, 22. Juli 2011 schrieb Michelle Konzack:
> Hello Martin Steigerwald,
> 
> Am 2011-07-22 10:36:07, hacktest Du folgendes herunter:
> > Wichtig ist bei TLS auf jeden Fall, den Client richtig einzustellen.
> > Denn wenn dieser das Passwort Klartext sendet, bringt es nichts,
> > wenn der Server TLS erfordert.
> 
> Nööö, viel zu hohes Risiko!
> 
> "plaintext auth"  im  Server  deaktivieren!
> 
> Funktioniert hier  einwandfrei  und  alle  MUAs  (Linux,  BSD, 
> Windows) switchen dann von selber zu TLS+SSL.

Aus meinem Telnet-Mitschnitt und meiner Mail auf die ich mich bezog, ist 
ersichtlich, dass unverschlüsslete Klartextpasswörter im Server 
deaktiviert sind, solange weder TLS noch SSL zum Einsatz kommt:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE 
STARTTLS LOGINDISABLED] Dovecot ready.

Capability LOGINDISABLED. Bei Dovecot ist das übrigens Standard-
Einstellung.

Ich weiß aber nicht, ob ein Client, der auf Plaintext gestellt ist, dann 
nicht trotzdem versucht, erstmal das Klartext-Passwort zu schicken. 
Genauso wie ich es in meinem Telnet-Mitschnitt demonstrierte:

a001 login testuser ghgfhg

Wenn ich auf dem Server STARTTLS als erforderlich konfiguriere, wie ich ja 
deutlich empfahl, dann hindert das den Client nicht, bei Fehlkonfiguration 
trotzdem erstmal Klartext zu schicken und *erst* dann auf die Schnauze zu 
fallen:

* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but 
your client did it anyway. If anyone was listening, the password was 
exposed.

Das ist anders, wenn ich über Port 993 gehe und der Port 143 geschlossen 
ist. Wenn da der Client noch auf Port 143 konfiguriert ist, kann er 
schlicht schonmal keine Verbindung aufbauen. Und ein Client, der über Port 
993 eine Verbindung aufbaut, sollte nicht mal auf die Idee kommen, es 
überhaupt mit einem unverschlüsselten Klartext-Passwort zu versuchen.

Klar, von einem intelligenten Client würde ich erwarten, dass er 
unabhängig von seiner Konfiguration niemals versucht, ein Klartext-Passwort 
zu verschicken, *egal* was der Benutzer eingestellt hat. Ob jedoch jeder 
Client "LOGINDISABLED" auswertet, bevor er das Anmelden versucht?

Oder meintest Du, plaintext unabhängig von SSL/TLS, also generell 
auszuschalten und nur noch eine der an sich schon verschlüsselten Anmelde-
Verfahren wie cram-md5, digest-md5 oder so zuzulassen?

Das könnte etwas mehr Sicherheit geben, denn die Auth-Verfahren müsste der 
Client ja auf jeden Fall vorher prüfen, aber auch da: Wenn der Client es 
bei Fehlkonfiguration trotzdem versucht?

Nun, da wäre jetzt in Quelltext des entsprechenden Clients, in die 
aktuelle Netzwerk-Kommunikation und die IMAP-Spezifikationen zu schauen. 
Wie geschrieben: Ein intelligenter Client prüft, ob er das Passwort 
unverschlüsselt im Klartext verschicken darf, bevor er es (mit dem echten 
Passwort) versucht.

So oder so, da sehe ich bei IMAPS durch die andere Portnummer eine etwas 
höhere Sicherheit, dass der Client das richtige (TM) macht.

Ein kleiner Test (mit falschem Passwort) - jetzt aber mit POP, da ich IMAP 
an sich privat (noch) nicht nutze - mit KMail liefert genau die 
Fehlermeldung von oben zurück. Es scheint mir also, als ob KMail es 
einfach ausprobiert.

Okay, laut Wireshark sendet KMail

USER benutzername\r\n

und fällt dann auf die Schnauze. Also es geht kein Passwort über die 
Leitung, obwohl KMail es einfach probiert. Allerdings ist POP3 einfach 
auch ein anderes Protokoll und das sieht dann anders aus:

martin@merkaba:~> telnet mondschein 110
Trying 194.150.191.11...
Connected to mondschein.lichtvoll.de.
Escape character is '^]'.
+OK Dovecot ready.

D.h. der Server meldet sich nicht mit den von IMAP bekannten Capabilities 
und daher weiß KMail initial ja auch nicht, was Sache ist. Durch die 
Trennung der Authentifizierung in zwei Befehle für Benutzer und Passwort 
ist das hier aber auch kein Problem.

Beim Login-Befehl von IMAP hab ich jedoch Benutzername und Passwort auf 
der gleichen Zeile angegeben.  Hier wäre interessant, zu schauen, was 
KMail dann macht. Da hab ich grad aber keine Lust mehr zu, da ich keinen 
IMAP-Account in KMail konfiguriert hab. Vielleicht ein andermal.

Hmmm, interessant wärs schon, aber ich hab noch ein paar andere Dinge zu 
erledigen. Wenn jemand anders grad die Muse hat, mal genauer zu schauen, 
oder es schon weiß... immer gerne.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Reply to: