Hello! At 15:22 19.03.2002 +0100, you wrote:
Some additional statements:
If the complete session is encrypted, why should you do an additional encryption for POP? Or for SMTP-AUTH? We have setup such systems for POP and SMTP, and after taking a deeper look into the log messages, I am quite sure that TLS-handshake occurs _before_ transmission of login and pass (as I also thought before I read your post), and before transmission of any data.
Here I don't understand you fully: My (probably faulty) setup takes care of an authentification before SMTP-relaying. Your protocol shows a complete SMTP session being encrypted. But POP is a different protocol used by a different server. If I would use someting like a "popper-tls", I (now) suppose it will encrypt the whole session too if setup correctly.
Yes, SMTP and POP are different protocols and in most cases implemented by different daemons. Sendmail is not a POP daemon, and thus, if a speak of a session, I mean an SMTP session (what I define as a session in this case has nothing to do with POP). Having said this, we can state that there are many POP-daemons with SSL capabilities and many SMTP daemons with TLS/SSL capabilities. On our systems, we encrypt all "mail" connections (which does mean the POP connections and the SMTP connections seperately) by using qpopper 4.0.3 for POP (which can be compiled and setup with support for TLS/SSL) and by using sendmail for SMTP (which can also be compiled and setup with support for TLS/SSL, as you have done). To make things more complicated, we do not use SMTP-AUTH but SMTP-after-POP. This means basically that if a POP client has authenticated successfully, then and only then the machine with the authenticated IP can use SMTP. Otherwise, SMTP connections are rejected. But this is not relevant for understanding the basic encryption mechanisms - I told only for the case that you wondered about the missing AUTH command from my ethereal output... which would not have seen anyway since it would have been encrypted.
As the complete session should be encryted after TLS handshake, you do not need to worry about clear-text passwords. Clear-text passwords only means that the encrypting extensions of the POP protocol are not used (such as APOP and others wich do this function _independently_ of TLS/SSL). But once again, don't care about this since the complete session, including "clear-text-passwords", is protected by crytography after successfull SSL/TLS handshake, and in the most cases, you don't need an additional password encryption for an already encrypted session.
I'm not very firm in this respect but did I get it correct now: TLS is sort of a "wrapper" around SMTP and POP transmissions? I thought it is a per server extension since it happens during the SMTP-dialogue. Also there is a separate sendmail-tls package - so I think only SMTP is protected using TLS whereas POP is not, at least I found no popper-tls.
Yes, TLS/SSL is a per server (and per client) extension (although there are also "tunnel daemons" and "tunnel clients" which you could use for every port and protocol). This extension adds the capability to negotiate a TLS/SSL session to the respective server or client. "Enhancing" a server or client means -besides other things- that there are eventually some additional commands for TLS/SSL negotiation and control which the server or client has to interpret correctly and that were not part of the "original" command set of the respective protocol. This extension which TLS/SSL constitutes wraps (encrypts), after it has been activated by some command, the following data exchange between server and client. Of course, the activation has to happen sometime during the dialogue between the client and the server, but then, all following data will be encrypted, regardless of its meaning. Since all session data is indeed going in clear text over the line _before_ the activation, the moment of activation is absolutely crucial. It has to happen before any login and password exchange. If this is the case, login, password, and all session commands and data follwing this are encrypted regardless of their meaning for the protocol. And as you correctly have stated above: If you don't have "popper-tls", then only your SMTP is protected.
Furthermore, from your ethereal output I can't see sendmail stating it's capabilities for TLS - look into the lines at the beginning which start with 250- . There is no line which says "250-STARTTLS" which would be the case if your sendmail daemon could use TLS. Taking all together, I am now pretty sure that you do not use TLS/SSL at all.
I'll recheck it shortly. I did install the sendmail-tls package and uninstalled normal sendmail. After reconfiguration and restart I used Netscape messenger with the TLS-Option set. So I _thought_ I'd use TLS. Lemme see...
I don't know the sendmail-tls package since we have compiled and configured ourselves. I Don't know Netscape messenger either, but there are very simple means of seeing if sendmail plays TLS or not. Please do the follwing: telnet <INSERT IP OF SENDMAIL DAEMON HERE> 25 There will be some lines of messages. Then type: EHLO localhost The answer will be some lines reading "250-.....". If there is a line which reads "250-STARTTLS" then: congratulations. Otherwise, your sendmail daemon does not speak tls. IMHO, a very simple and effective test which has the great advantage that it is client-independent! Regards, Peter Pfannenschmid
Example correct session log:
220 sisko.itc.de ESMTP Sendmail 8.12.2/8.12.2; Tue, 19 Mar 2002 12:45:13 +0100 EHLO kira.t-online.de 250-sisko.itc.de Hello kira.itc.de [192.168.10.10], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-STARTTLS 250-DELIVERBY 250 HELP STARTTLS 220 2.0.0 Ready to start TLS [ W <%üëuUKÊTHqÂiH~á¹ãH¯¿à 0 J H fÿ I ÿ d b e cÿ J F <$É#[ÿ~Ãßãpƪ¦s¸lh¤4-Ût!Vú I}Ý÷ØÃW7q [ APPROX 3000 bytes more debris of the above sort from here...]
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here