Cyrus imapd über SSL/TLS nur mit Zertifikat?
Hallo Liste, ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist. Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993. Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. Ein Text-Login würde dadurch nicht wesentlich erschwert. Daher die Idee, die Authorisierung über Text-Passwort für Port 993 zu unterbinden und nur eine Authorisierung über ein Zertifikat o.ä. zu erlauben, ähnlich wie es auch mit ssh-Verbindungen möglich ist. In der imapd.conf könnte ich eintragen: allowplaintext: no aber das würde ja auch den lokalen Zugang über Port 143 betreffen. Kann mir jemand einen Hinweis geben, wie diese Konfiguration realisiert werden kann? Danke und viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 21.12.2007 14:11, Martin Burnicki wrote (please find the answer below the original text):
Hallo Liste,
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ein Text-Login würde dadurch nicht wesentlich erschwert.
Ähm, erschwertes Textlogin? Was ist das? -Ingo. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo,
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ich denke, hier liegt ein Mißverständnis vor; bei imaps wird für die verbindung mit dem imap-Server in SSL-Tunnel aufgebaut, alle Daten, die dadurch gehen (egal ob nun nochmals extra verschlüsselt oder nicht) sind somit mittels SSL geschützt. (SSL oder TSL, bin zu faul, immer beides zu schreiben.) Auch die Anmeldedaten werden über diesen Tunnel übertragen, entsprechend sind sie auch verschlüsselt. Eine recht einfach gehaltene Anleitung zur Konfiguration findet sich unter http://www.dr-lotz.de/cyrus-imap.php
Ein Text-Login würde dadurch nicht wesentlich erschwert.
Ähm, erschwertes Textlogin? Was ist das?
Ich vermute, es ist ein Cleartext-Login (mit der Authentifizierunghsmethode Plain) gemeint. Auch der wird durch diese Geschichte natütlich verschlüsselt. Die Option tls_require_cert: 1 sollte, wenn ich das richtig in der imapd.conf-Manpage gesehen haben, dafür sorgen, dass Clients über ein entsprechendes Zertifikat verfügen müssen, um überhaupt Kontakt aufnehmen zu können. Bestimmt lässt sich auch die Authentifizierung als solche mit einem Nutzerzertifikat koppeln, da weiss ich jetzt aber so aus dem Kopf nicht wie. Wenn das hier von Interesse ist kann ich es nochmal nachsene. Bis denne, Ortwin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Ortwin Ebhardt schrieb:
Ingo Freund schrieb:
Martin Burnicki schrieb:
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ich denke, hier liegt ein Mißverständnis vor; bei imaps wird für die verbindung mit dem imap-Server in SSL-Tunnel aufgebaut, alle Daten, die dadurch gehen (egal ob nun nochmals extra verschlüsselt oder nicht) sind somit mittels SSL geschützt. (SSL oder TSL, bin zu faul, immer beides zu schreiben.) Auch die Anmeldedaten werden über diesen Tunnel übertragen, entsprechend sind sie auch verschlüsselt.
Genau. Aber meines Wissens verhindert die Verschlüsselung durch den Tunnel lediglich, dass durch Abhorchen des Datenverkehrs das Passwort herausgefunden werden kann.
Eine recht einfach gehaltene Anleitung zur Konfiguration findet sich unter
Danke, werde ich mir ansehen.
Ein Text-Login würde dadurch nicht wesentlich erschwert.
Ähm, erschwertes Textlogin? Was ist das?
Mit "Textlogin" meinte ich die einfache Anmeldung durch Benutzername und Passwort. Eigentlich würde ich die Bezeichnung "Plain Text" damit in Verbindung bringen. In kmail kann man allerdings unter "Anmeldeverfahren" u.a. auswählen zwischen "Einfacher Text" und "PLAIN". Keine Ahnung, wo da der Unterschied ist, oder ob es sich lediglich um ein Übersetzungsproblem handelt.
Ich vermute, es ist ein Cleartext-Login (mit der Authentifizierunghsmethode Plain) gemeint. Auch der wird durch diese Geschichte natütlich verschlüsselt.
Ja. Aber um eine verschlüsselte Verbindung aufzubauen, genügt ein Zertifikat auf dem Server, ähnlich wie bei einer https-Verbindung. Wenn der Tunnel einmal steht und Cleartext-Login erlaubt ist, kann ein Angreifer einfach ein paar Passworte ausprobieren, um sich anzumelden. D.h. ob er Zugang zu dem Account erhält oder nicht hängt nur von der Crack-Sicherheit des Passworts ab. Also abgesehen von der fehlenden Abhörmöglichkeit der Verbindung bietet IMAPS allein keine höhere Sicherheit gegen unbefugten Zugang zu einem Account als ein normaler IMAP-Zugang. Falls ich das falsch verstehe, möge man mich bitte aufklären ;-)
Die Option
tls_require_cert: 1
sollte, wenn ich das richtig in der imapd.conf-Manpage gesehen haben, dafür sorgen, dass Clients über ein entsprechendes Zertifikat verfügen müssen, um überhaupt Kontakt aufnehmen zu können. Bestimmt lässt sich auch die Authentifizierung als solche mit einem Nutzerzertifikat koppeln, da weiss ich jetzt aber so aus dem Kopf nicht wie. Wenn das hier von Interesse ist kann ich es nochmal nachsene.
Danke, das ist ein guter Hinweis. ich werde mal sehen, ob ich in die Richtung weiterkomme. Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 02.01.2008 12:26, Martin Burnicki wrote (please find the answer below the original text):
Hallo,
Ortwin Ebhardt schrieb:
Ingo Freund schrieb:
Martin Burnicki schrieb:
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ich denke, hier liegt ein Mißverständnis vor; bei imaps wird für die verbindung mit dem imap-Server in SSL-Tunnel aufgebaut, alle Daten, die dadurch gehen (egal ob nun nochmals extra verschlüsselt oder nicht) sind somit mittels SSL geschützt. (SSL oder TSL, bin zu faul, immer beides zu schreiben.) Auch die Anmeldedaten werden über diesen Tunnel übertragen, entsprechend sind sie auch verschlüsselt.
Genau. Aber meines Wissens verhindert die Verschlüsselung durch den Tunnel lediglich, dass durch Abhorchen des Datenverkehrs das Passwort herausgefunden werden kann.
Ja genau, deshalb ja auch meine Frage woher das Wissen über die "Nur- Datenverschlüsselung" kommt. Das klang so, als wenn die Anmeldedaten (User/Passwort) nicht verschlüsselt würden, was natürlich nicht der Fall ist. Zudem stellt sich die Frage, was denn nun eigentlich gewünscht ist, schließlich sind bei imaps _alle_ Daten encrypted und damit praktisch nicht abhörbar geschützt.
Eine recht einfach gehaltene Anleitung zur Konfiguration findet sich unter
Danke, werde ich mir ansehen.
Ein Text-Login würde dadurch nicht wesentlich erschwert.
Wenn damit gemeint ist, dass trotz SSL-Forderung auf dem Port 993 eine unverschlüsselte Anmeldung möglich sein sollte, dann ist diese Annahme falsch. imaps-Funktion: Ein SSL-Zertifikat muß vorliegen und der Client möglichst das Root-CA kennen (ggf. improtieren), sonst meckert er über ein angeblich "Ungültiges Zertifikat". Client und Server einigen sich nach dem Austausch der Zertifikatsdaten und der gegenseitigen Anerkennung im Handshake über die Verschlüsselung. Ab dann ist die Verbindung encrypted. Nun gibt es die Authentifizierung mit den Anmeldedaten und den Datenaustausch. Das ganze ist natürlich in den bekannten Konfigurationsdateien einzustellen! [...] -Ingo. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Ingo, Ingo Freund schrieb:
On 02.01.2008 12:26, Martin Burnicki wrote (please find the answer below the original text):
Hallo,
Ortwin Ebhardt schrieb:
Ingo Freund schrieb:
Martin Burnicki schrieb:
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ich denke, hier liegt ein Mißverständnis vor; bei imaps wird für die verbindung mit dem imap-Server in SSL-Tunnel aufgebaut, alle Daten, die dadurch gehen (egal ob nun nochmals extra verschlüsselt oder nicht) sind somit mittels SSL geschützt. (SSL oder TSL, bin zu faul, immer beides zu schreiben.) Auch die Anmeldedaten werden über diesen Tunnel übertragen, entsprechend sind sie auch verschlüsselt. Genau. Aber meines Wissens verhindert die Verschlüsselung durch den Tunnel lediglich, dass durch Abhorchen des Datenverkehrs das Passwort herausgefunden werden kann.
Ja genau, deshalb ja auch meine Frage woher das Wissen über die "Nur- Datenverschlüsselung" kommt. Das klang so, als wenn die Anmeldedaten (User/Passwort) nicht verschlüsselt würden, was natürlich nicht der Fall ist.
Mit "Datenverschlüsselung" meinte ich jeglichen Datenaustausch zwischen dem Client und dem Server durch den Tunnel. Dazu gehört natürlich sowohl die Anmeldung als auch die Übertragung abgeholter Header und Nachrichten über das IMAP-Protokoll.
Zudem stellt sich die Frage, was denn nun eigentlich gewünscht ist, schließlich sind bei imaps _alle_ Daten encrypted und damit praktisch nicht abhörbar geschützt.
Wie ich schon schrieb, der Tunnel verhindert nur das Ausspionieren des Passworts durch Mithorchen an der Leitung. [...]
Ein Text-Login würde dadurch nicht wesentlich erschwert.
Wenn damit gemeint ist, dass trotz SSL-Forderung auf dem Port 993 eine unverschlüsselte Anmeldung möglich sein sollte, dann ist diese Annahme falsch.
Nein, im Gegensatz zu Port 143 auf dem gleichen Server sollte eben über Port 993 gerade keine Anmeldung mit Passwort möglich sein. Stattdessen sollte über Port 993 ausschließlich ein user-spezifisches Zertifikat verwendet werden dürfen, wie es auch beim passwort-losen Login über ssh verwendet wird (Stichwort ~/.ssh/id_rsa.pub, ~/.ssh/authorized_keys).
imaps-Funktion: Ein SSL-Zertifikat muß vorliegen und der Client möglichst das Root-CA kennen (ggf. improtieren), sonst meckert er über ein angeblich "Ungültiges Zertifikat". Client und Server einigen sich nach dem Austausch der Zertifikatsdaten und der gegenseitigen Anerkennung im Handshake über die Verschlüsselung. Ab dann ist die Verbindung encrypted.
Genau. Dann steht der Tunnel. Um den Tunnel aufzubauen, muß ein Bösewicht ;-) nur seinen Email-Client für IMAPS konfigurieren und ggf. das Zertifikat des Servers zu akzeptieren.
Nun gibt es die Authentifizierung mit den Anmeldedaten und den Datenaustausch.
Und wenn das Passwort leicht zu erraten ist, ist der Bösewicht dann drin und hat Zugriff auf die Emails. Da der bewußte Mailserver bisher nur innerhalb eines vertrauenswürdigen Intranets per IMAP (ohne TLS/SSL) erreichbar war, sind sicherlich einige Passwörter nicht allzu sicher. Daher die Idee, den Zugang von außen nur über ein user-spezifisches Zertifikat zu erlauben und das Text-Loginzu verhindern. Die zur Authorisierung der Benutzer verwendeten Zertifikate müssen und sollten nichts mit dem Zertifikat zu tun haben, welches die SSL-/TLS-Schicht zum Aufbau des Tunnels verwendet.
Das ganze ist natürlich in den bekannten Konfigurationsdateien einzustellen!
Und hier kommen wir zum Kern: Mit welchem Parameter erreiche ich das gewünschte Verhalten? Die von Ortwin erwähnte Konfigurations-Option tls_require_cert: 1 hört sich vielversprechend an, also werde ich in diese Richtung weitersuchen. Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Martin, * On Wed, Jan 02, 2008 at 02:59 PM, Martin Burnicki wrote:
Ingo Freund schrieb:
On 02.01.2008 12:26, Martin Burnicki wrote (please find the answer below the original text):
Hallo,
Ortwin Ebhardt schrieb:
Ingo Freund schrieb:
Martin Burnicki schrieb:
ich habe hier einen cyus imapd, der aus dem (kleinen) internen Netz direkt über imap-Protokoll mit einfachem Text-Passwort erreichbar ist.
Zusätzlich sollte der Server jetzt auch von extern erreichbar sein, jedoch ausschließlich über imaps-Protokoll / Port 993.
Ich weiß, dass imaps nur den Datenverkehr verschlüsselt. [...]
Absolut sicher? Woher kommt dieses Wissen?
Ich denke, hier liegt ein Mißverständnis vor; bei imaps wird für die verbindung mit dem imap-Server in SSL-Tunnel aufgebaut, alle Daten, die dadurch gehen (egal ob nun nochmals extra verschlüsselt oder nicht) sind somit mittels SSL geschützt. (SSL oder TSL, bin zu faul, immer beides zu schreiben.) Auch die Anmeldedaten werden über diesen Tunnel übertragen, entsprechend sind sie auch verschlüsselt. Genau. Aber meines Wissens verhindert die Verschlüsselung durch den Tunnel lediglich, dass durch Abhorchen des Datenverkehrs das Passwort herausgefunden werden kann.
Ja genau, deshalb ja auch meine Frage woher das Wissen über die "Nur- Datenverschlüsselung" kommt. Das klang so, als wenn die Anmeldedaten (User/Passwort) nicht verschlüsselt würden, was natürlich nicht der Fall ist.
Mit "Datenverschlüsselung" meinte ich jeglichen Datenaustausch zwischen dem Client und dem Server durch den Tunnel. Dazu gehört natürlich sowohl die Anmeldung als auch die Übertragung abgeholter Header und Nachrichten über das IMAP-Protokoll.
Zudem stellt sich die Frage, was denn nun eigentlich gewünscht ist, schließlich sind bei imaps _alle_ Daten encrypted und damit praktisch nicht abhörbar geschützt.
Wie ich schon schrieb, der Tunnel verhindert nur das Ausspionieren des Passworts durch Mithorchen an der Leitung.
Nein. Wenn Du IMAP über TLS/SSL machst, gehen sowohl Logindaten (also Benutzername und Passwort) als auch die Nutzdaten (eMail-Header, eMail- Bodys, Steuerinformationen) durch den Tunnel. Sie sind dann allesamt nicht mehr im Klartext auf der Leitung und damit nur dann von einem Dritten abhörbar, wenn er den SSH-Tunnel geknackt hätte. Es wird also "alles" verschlüsselt, nicht nur das Login. Auch das Mit- lesen der Nachrichten selbst wird so praktisch unmöglich gemacht. Du kannst es ja leicht überprüfen, indem Du z.B. mit "wireshark" mal die Pakete abfängst, die auf dem betreffenden Interface hereinkommen. Gruß, Steffen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Steffen, Steffen Moser schrieb:
Martin Burnicki schrieb: Mit "Datenverschlüsselung" meinte ich jeglichen Datenaustausch zwischen dem Client und dem Server durch den Tunnel. Dazu gehört natürlich sowohl die Anmeldung als auch die Übertragung abgeholter Header und Nachrichten über das IMAP-Protokoll.
Zudem stellt sich die Frage, was denn nun eigentlich gewünscht ist, schließlich sind bei imaps _alle_ Daten encrypted und damit praktisch nicht abhörbar geschützt. Wie ich schon schrieb, der Tunnel verhindert nur das Ausspionieren des Passworts durch Mithorchen an der Leitung.
Nein. Wenn Du IMAP über TLS/SSL machst, gehen sowohl Logindaten (also Benutzername und Passwort) als auch die Nutzdaten (eMail-Header, eMail- Bodys, Steuerinformationen) durch den Tunnel. Sie sind dann allesamt nicht mehr im Klartext auf der Leitung und damit nur dann von einem Dritten abhörbar, wenn er den SSH-Tunnel geknackt hätte.
Es wird also "alles" verschlüsselt, nicht nur das Login. Auch das Mit- lesen der Nachrichten selbst wird so praktisch unmöglich gemacht.
Du kannst es ja leicht überprüfen, indem Du z.B. mit "wireshark" mal die Pakete abfängst, die auf dem betreffenden Interface hereinkommen.
Hm, (fast) keiner versteht mich ;-( Das ist doch genau, was ich ganz oben schrieb. _Alles_, was durch den Tunnel geht, wird verschlüsselt. Aber was hindert einen Angreifer daran, selbst einen Tunnel aufzubauen? Er braucht dazu nur das Zertifikat des Servers zu akzeptieren (wie bei https). Wenn der Tunnel steht, kann er versuchen, sich mit verschiedenen Passworten anzumelden, die er im Klartext bei seinem Email-Programm eingibt. Wenn er das richtige Passwort erwischt, ist er "drin" und hat Zugriff auf alle Emails des Accounts. Die Art des Angriffs unterscheidet sich nicht von einem Angriff auf einen "normalen" IMAP-Server ohne TLS/SSL, außer dass im letzten Fall das Passwort durch einen Sniffer herausgefunden werden kann, falls der Angreifer an die Leitung herankommt. _Das_ geht bei Verwendung von TLS/SSL nicht. Zur Erinnerung: Einige der Accounts verwenden sicherlich nur "schwache" Passwörter, da der Mailserver bisher nur aus dem vertrauenswürdigen Intranet heraus erreichbar ist. Der IMAP-Zugang aus dem Intranet soll wie gehabt erhalten bleiben, aus dem Internet soll der Zugang jedoch nicht mit Klartext-Passwörtern möglich sein. Daher die Idee, IMAPS zu verwenden und Anmeldung mit Klartext-Passwörtern über IMAPS zu verbieten. Gruß, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Martin Burnicki wrote:
Hallo Steffen,
Steffen Moser schrieb:
Martin Burnicki schrieb: Mit "Datenverschlüsselung" meinte ich jeglichen Datenaustausch zwischen dem Client und dem Server durch den Tunnel. Dazu gehört natürlich sowohl die Anmeldung als auch die Übertragung abgeholter Header und Nachrichten über das IMAP-Protokoll.
Zudem stellt sich die Frage, was denn nun eigentlich gewünscht ist, schließlich sind bei imaps _alle_ Daten encrypted und damit praktisch nicht abhörbar geschützt. Wie ich schon schrieb, der Tunnel verhindert nur das Ausspionieren des Passworts durch Mithorchen an der Leitung. Nein. Wenn Du IMAP über TLS/SSL machst, gehen sowohl Logindaten (also Benutzername und Passwort) als auch die Nutzdaten (eMail-Header, eMail- Bodys, Steuerinformationen) durch den Tunnel. Sie sind dann allesamt nicht mehr im Klartext auf der Leitung und damit nur dann von einem Dritten abhörbar, wenn er den SSH-Tunnel geknackt hätte.
Es wird also "alles" verschlüsselt, nicht nur das Login. Auch das Mit- lesen der Nachrichten selbst wird so praktisch unmöglich gemacht.
Du kannst es ja leicht überprüfen, indem Du z.B. mit "wireshark" mal die Pakete abfängst, die auf dem betreffenden Interface hereinkommen.
Hm, (fast) keiner versteht mich ;-(
Das ist doch genau, was ich ganz oben schrieb. _Alles_, was durch den Tunnel geht, wird verschlüsselt.
Aber was hindert einen Angreifer daran, selbst einen Tunnel aufzubauen? Er braucht dazu nur das Zertifikat des Servers zu akzeptieren (wie bei https).
Clientzertifikate: Der Server akzeptiert nur die Zertifikate, die von der CA kommen, die beim Server als vertrauenswürdig eingetragen sind. Das ist der Unterschied, wenn der Server explizit nach einem Clientzertifikat fragt im Gegensatz zu einem verschlüsselten Tunnel. Der eingetragene Name (common name) im Zertifikat dient dann zur Authentifikation des Clients. Verschlüsselter Tunnel: Der Server einigt sich mit dem Client auf ein gemeinsames Verfahren zur Verschlüsselung, der common name des Client dient nicht nur Authentifikation, der Client bekommt eine Warnung, wenn die CA des Server-Zertifikats nicht in seiner Liste der vertrauenswürdigen Zertifikate besteht, kann dieses aber trotzdem akzeptieren. Cyrus spezifisch: Wie üblich ist die Dokumentation für Cyrus besch... eiden, höflich ausgedrückt. Aber hier ein Ausschnitt aus einer Releasenote: Update of /afs/andrew/system/cvs/src/cyrus/man In directory unix3.andrew.cmu.edu:/usr/tmp/cvs-serv1931/man Modified Files: imapd.conf.5 Log Message: added tls*_require_cert option Index: src/cyrus/man/imapd.conf.5 diff -u src/cyrus/man/imapd.conf.5:1.59 src/cyrus/man/imapd.conf.5:1.60 --- src/cyrus/man/imapd.conf.5:1.59 Sat May 25 15:57:48 2002 +++ src/cyrus/man/imapd.conf.5 Sun Jun 2 11:25:43 2002 @@ -39,7 +39,7 @@ .\" AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING .\" OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: imapd.conf.5,v 1.59 2002/05/25 19:57:48 leg Exp $ +.\" $Id: imapd.conf.5,v 1.60 2002/06/02 15:25:43 ken3 Exp $ .SH NAME imapd.conf \- IMAP configuration file .SH DESCRIPTION @@ -258,10 +258,12 @@ file overrides the SASL configuration file. .IP "\fBtls_cert_file:\fR <none>" 5 File containing the global certificate used for ALL services (imap, -pop3, lmtp). +pop3, lmtp, sieve). .IP "\fBtls_key_file:\fR <none>" 5 File containing the private key belonging to the global server certificate. +.IP "\fBtls_require_cert:\fR 0" 5 +Require a client certificate for ALL services (imap, pop3, lmtp, sieve). .IP "\fBtls_imap_cert_file:\fR <none>" 5 File containing the certificate used for imap ONLY. If not specified, the global certificate is used. A value of "disabled" will disable @@ -270,6 +272,8 @@ File containing the private key belonging to the imap-specific server certificate. If not specified, the global private key is used. A value of "disabled" will disable SSL/TLS for imap. +.IP "\fBtls_imap_require_cert:\fR 0" 5 +Require a client certificate for imap ONLY. .IP "\fBtls_pop3_cert_file:\fR <none>" 5 File containing the certificate used for pop3 ONLY. If not specified, the global certificate is used. A value of "disabled" will disable @@ -278,6 +282,8 @@ File containing the private key belonging to the pop3-specific server certificate. If not specified, the global private key is used. A value of "disabled" will disable SSL/TLS for pop3. +.IP "\fBtls_pop3_require_cert:\fR 0" 5 +Require a client certificate for pop3 ONLY. .IP "\fBtls_lmtp_cert_file:\fR <none>" 5 File containing the certificate used for lmtp ONLY. If not specified, the global certificate is used. A value of "disabled" will disable @@ -286,6 +292,8 @@ File containing the private key belonging to the lmtp-specific server certificate. If not specified, the global private key is used. A value of "disabled" will disable TLS for lmtp. +.IP "\fBtls_lmtp_require_cert:\fR 0" 5 +Require a client certificate for lmtp ONLY. .IP "\fBtls_sieve_cert_file:\fR <none>" 5 File containing the certificate used for sieve ONLY. If not specified, the global certificate is used. A value of "disabled" will disable @@ -294,6 +302,8 @@ File containing the private key belonging to the sieve-specific server certificate. If not specified, the global private key is used. A value of "disabled" will disable TLS for sieve. +.IP "\fBtls_sieve_require_cert:\fR 0" 5 +Require a client certificate for sieve ONLY. .IP "\fBtls_ca_file:\fR <none>" 5 File containing one or more Certificate Authority (CA) certificates. .IP "\fBtls_ca_path:\fR <none>" 5 Die Man-Page kennt nur auf tls_require_cert. :-(( Um für externe und interne Clients unterschiedliche Bedingungen zu präsentieren, musst du die Serverkonfig auf diesen Ports abändern. Auf den ersten Blick habe ich aber nicht feststellen können, ob sich der Konfigpfad für eine zweite Instanz ändern lässt (per -use-config-file oder ähnliches für eine zweite Instanz). Die einzige Option in der man page war ein tcp wrapper, der auf IP-Basis entscheidet, ob der Zugriff auf einen service in /etc/cyrus.conf erlaubt ist oder nicht. Für eine Unterscheidung internes Netz / Internet sollte es reichen. Ohne Sourcecode-Analyse und Änderung wirst du wohl nicht ans Ziel kommen. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, Sandy Drobic schrieb:
Clientzertifikate:
Der Server akzeptiert nur die Zertifikate, die von der CA kommen, die beim Server als vertrauenswürdig eingetragen sind. Das ist der Unterschied, wenn der Server explizit nach einem Clientzertifikat fragt im Gegensatz zu einem verschlüsselten Tunnel. Der eingetragene Name (common name) im Zertifikat dient dann zur Authentifikation des Clients.
Yep, das ist, was ich benötige.
Verschlüsselter Tunnel:
Der Server einigt sich mit dem Client auf ein gemeinsames Verfahren zur Verschlüsselung, der common name des Client dient nicht nur Authentifikation, der Client bekommt eine Warnung, wenn die CA des Server-Zertifikats nicht in seiner Liste der vertrauenswürdigen Zertifikate besteht, kann dieses aber trotzdem akzeptieren.
So habe ich das auch verstanden.
Cyrus spezifisch:
Wie üblich ist die Dokumentation für Cyrus besch... eiden, höflich ausgedrückt.
Das ist das Problem. Und wenn man sich nur selten damit beschäftigt, ist man doch nicht so sehr mit den Konfigurationsparametern vertraut.
Aber hier ein Ausschnitt aus einer Releasenote:
Update of /afs/andrew/system/cvs/src/cyrus/man In directory unix3.andrew.cmu.edu:/usr/tmp/cvs-serv1931/man
Modified Files: imapd.conf.5 Log Message: added tls*_require_cert option [...] Die Man-Page kennt nur auf tls_require_cert. :-((
Traurig, dass die einzelnen Optionen nicht in der Man-Page erwähnt werden. Oder sind sie zwischenzeitlich wieder rausgeflogen? Das Changelog ist ja bereits von 2002 ...
Um für externe und interne Clients unterschiedliche Bedingungen zu präsentieren, musst du die Serverkonfig auf diesen Ports abändern. Auf den ersten Blick habe ich aber nicht feststellen können, ob sich der Konfigpfad für eine zweite Instanz ändern lässt (per -use-config-file oder ähnliches für eine zweite Instanz).
Daran habe ich auch schon gedacht, in cyrus.conf unterschiedliche imapd.conf-Dateien für imap und imaps anzugeben. Aber evt. geht es auch anders. Siehe unten.
Die einzige Option in der man page war ein tcp wrapper, der auf IP-Basis entscheidet, ob der Zugriff auf einen service in /etc/cyrus.conf erlaubt ist oder nicht. Für eine Unterscheidung internes Netz / Internet sollte es reichen.
Ohne Sourcecode-Analyse und Änderung wirst du wohl nicht ans Ziel kommen.
Die in den Emails von Ortwin und Dir erwähnte Option "tls_require_cert" kann wohl durch eine weitere Option "allowplainwithouttls" entschärft werden. Ich habe jetzt eine Testmaschine aufgesetzt mit den Optionen tls_require_cert: yes allowplainwithouttls: yes Ohne diese Optionen konnte ich den IMAP-Server mit und ohne TLS/SSL mit Klartext-Passwort erreichen. Mit diesen Optionen geht Klartext-Login nur noch über Port 143, über Port 993 kommt keine Verbindung mehr zustande. Der Fehler ist: "imaps TLS negotiation failed". Ich muß jetzt nur noch ein Client-Zertifikat erzeugen und dann sehen, ob es damit auch mit TLS wieder geht ... Danke für die Hilfe und viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (5)
-
Ingo Freund -
Martin Burnicki -
Ortwin Ebhardt -
Sandy Drobic -
Steffen Moser