Re: [suse-security] What to do against ARP-Poisoning?

newer
how can i unsubscribe ?

older
FW: SCP from Server to Server...

Roland Hilkenbach

18 Mar 2002 18 Mar '02

16:26

Am Montag, 18. März 2002 15:59 schrieb Peter Pfannenschmid:

...

Hello,

just one quick question: is it really true that sendmail-tls/ssl and qpopper-tls/ssl does NOT encrypt message bodies (as stated below)? I do not want to believe this...

Thank your very much,

Peter Pfannenschmid

I felt too bad to show up with an example from Exchange so I used a server of a friend of mine to verify that TLS-Messages are send in plain text using sendmail-tls. Here's the ethereal-output again with some entries blackened: 220 xxxxxx.pureserver.de ESMTP Sendmail 8.11.3/8.11.3/SuSE Linux 8.11.1-0.5; Mon, 18 Mar 2002 17:19:32 +0100 EHLO profil-hannover.de 250-xxxxxx.pureserver.de Hello pD9E35E24.dip.t-dialin.net [217.227.94.36], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250-AUTH LOGIN PLAIN 250 HELP AUTH PLAIN xxxxxxxxxxxxxxxxxxx= 235 2.0.0 OK Authenticated MAIL FROM: 250 2.1.0 ... Sender ok RCPT TO: 250 2.1.5 ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Sender: roland Message-ID: <3C9613A8.EB203A30@profil-hannover.de> Date: Mon, 18 Mar 2002 17:19:52 +0100 From: Roland Hilkenbach X-Mailer: Mozilla 4.78 [de] (X11; U; Linux 2.4.10-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: rh@profil-hannover.de Subject: Testmail via sendmail TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo und moin moin . 250 2.0.0 g2IGJcr06461 Message accepted for delivery QUIT 221 2.0.0 xxxxxx.pureserver.de closing connection I hope you excuse me using an exchange server for the previous example ;-) Roland Hilkenbach

Show replies by date

Peter Pfannenschmid

19 Mar 19 Mar

12:45

New subject: [suse-security] What to do against ARP-Poisoning?

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 still think that after a successfull TLS handshake the complete session would be encrypted, including any type of authentication, especially clear text authentication. 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. 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. 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. 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. 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 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...] At 17:26 18.03.2002 +0100, Roland Hilkenbach wrote:

...

Am Montag, 18. März 2002 15:59 schrieb Peter Pfannenschmid:

...
Hello,

just one quick question: is it really true that sendmail-tls/ssl and qpopper-tls/ssl does NOT encrypt message bodies (as stated below)? I do not want to believe this...

Thank your very much,

Peter Pfannenschmid

I felt too bad to show up with an example from Exchange so I used a server of a friend of mine to verify that TLS-Messages are send in plain text using sendmail-tls. Here's the ethereal-output again with some entries blackened:

220 xxxxxx.pureserver.de ESMTP Sendmail 8.11.3/8.11.3/SuSE Linux 8.11.1-0.5; Mon, 18 Mar 2002 17:19:32 +0100 EHLO profil-hannover.de 250-xxxxxx.pureserver.de Hello pD9E35E24.dip.t-dialin.net [217.227.94.36], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250-AUTH LOGIN PLAIN 250 HELP AUTH PLAIN xxxxxxxxxxxxxxxxxxx= 235 2.0.0 OK Authenticated MAIL FROM: 250 2.1.0 ... Sender ok RCPT TO: 250 2.1.5 ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Sender: roland Message-ID: <3C9613A8.EB203A30@profil-hannover.de> Date: Mon, 18 Mar 2002 17:19:52 +0100 From: Roland Hilkenbach X-Mailer: Mozilla 4.78 [de] (X11; U; Linux 2.4.10-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: rh@profil-hannover.de Subject: Testmail via sendmail TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

Hallo und moin moin . 250 2.0.0 g2IGJcr06461 Message accepted for delivery QUIT 221 2.0.0 xxxxxx.pureserver.de closing connection

I hope you excuse me using an exchange server for the previous example ;-)

Roland Hilkenbach

-- 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

Roland Hilkenbach

14:22

New subject: [suse-security] What to do against ARP-Poisoning?

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...]

Peter Pfannenschmid

18:16

New subject: [suse-security] What to do against ARP-Poisoning?

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

8085

Age (days ago)

8086

Last active (days ago)

List overview

Download

3 comments

2 participants

participants (2)

Peter Pfannenschmid
Roland Hilkenbach