Am Dienstag, 19. März 2002 13:45 schrieb Peter Pfannenschmid:
Hello,
I don't think that your TLS/SSL is set up correctly. According to your ethereal output, there is absolutely no handshake for TLS/SSL nor any transmission of some certificate. If your client / server was indeed handshaking TLS/SSL, there should be visible at least a certificate exchange in the sniffed connection. So I think you are not using TLS/SSL in this case. There could be multiple causes of this.
I overwrote the binary data with Xx's, so at least there is happening something with the authentification. Without sendmail-tls there simply is no AUTH in the stream.
I still think that after a successfull TLS handshake the complete session would be encrypted, including any type of authentication, especially clear text authentication.
It is quite possible, that I made a mistake setting up the server. I just kept close to the description in the FAQs from Puretec and I'm just beginning to learn about the features of sendmail-tls.
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.
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.
An additional tip:
Look into the log files of the _server_ system, which is hopefully unix or linux. If there are no messages stating a successfull TLS handshake, then there was no such handshake, and you did not use TLS at all.
I will do - promised.
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...
Please read the ethereal output of a real TLS session (taken from our systems) which I have put below. Note especially the line 250-STARTTLS after the client HELO, and note also the contents of the certificate. After transmission of the certificate, there is no plain text, and no plain login or password. I did not want to post the rest (3000 bytes of encrypted debris) here, so I would like you to just believe me that there was not a single reasonable combination of letters in the rest of the output.
Regards,
Peter Pfannenschmid
Thank you a lot for your answer. It gave me a lot to think and to experiment. Roland Hilkenbach
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...]