determining whether a server supports secure authentication

[Uno]

Hello newsgroup,

I'm trying to use thunderbird to get an e-mail capability on linux, and
since this is the only reason I have to boot windows at all, I'd like to
figure it out.

Where I'm stuck right now is that I know OE uses SSL authentication to
get my mail successfully when I ask for it, but the t-bird set-up is
telling me that the server does not support it.

http://i42.tinypic.com/s5vktk.jpg

This image shows what qwest says are the thunderbird settings. I admit
the possibility that qwest is a crappy corporation with misleading
information, but the evidence points elsewhere.

When I change thunderbird's settings to be analogous to the above, then
I get this:

http://i39.tinypic.com/28ulb3d.jpg

Can I use the perl programming language to determine whether what type
of authentication this server understands?

Thanks for your comment and cheers,

 

[Peter J. Holzer]

I'm trying to use thunderbird to get an e-mail capability on linux, and
since this is the only reason I have to boot windows at all, I'd like to
figure it out.

Where I'm stuck right now is that I know OE uses SSL authentication to
get my mail successfully when I ask for it, but the t-bird set-up is
telling me that the server does not support it. [...]
http://i39.tinypic.com/28ulb3d.jpg

"SSL Authentication" != "Secure Authentication".

You probably just have to turn "Secure Authentication" off (but leave
STARTTLS on).

Can I use the perl programming language to determine whether what type
of authentication this server understands?

Yes. However, you don't have to write that program yourself, as somebody
has already done it: Look for "swaks" (the SWiss Army Knife for Smtp).
Some linux distributions (e.g. Debian) include it, or you can download
it from http://www.jetmore.org/john/code/swaks/

hp

 

[Uno]

I'm trying to use thunderbird to get an e-mail capability on linux, and
since this is the only reason I have to boot windows at all, I'd like to
figure it out.

Where I'm stuck right now is that I know OE uses SSL authentication to
get my mail successfully when I ask for it, but the t-bird set-up is
telling me that the server does not support it. [...]
http://i39.tinypic.com/28ulb3d.jpg

"SSL Authentication" != "Secure Authentication".

You probably just have to turn "Secure Authentication" off (but leave
STARTTLS on).

What was going on here was that I was conflating secure connections and
secure authentication. The latter is an MS thing, and the whole picture
you get of it as a windows user slightly distorts what is actually
happening.

I was "sure" that I was using SSL, and in my head it sounded right that
a secure socket layer would employ secure authentication. They are
completely separate notions.

So, problem solved by unchecking a box.

Yes. However, you don't have to write that program yourself, as somebody
has already done it: Look for "swaks" (the SWiss Army Knife for Smtp).
Some linux distributions (e.g. Debian) include it, or you can download
it from http://www.jetmore.org/john/code/swaks/

Well, hot damn:

$ swaks --to (e-mail address removed) --server pop3.live.com

=== Trying pop3.live.com:25...
*** Error connecting 0.0.0.0 to pop3.live.com:25:
*** IO::Socket::INET: connect: timeout
$ swaks --to (e-mail address removed) --server smtp.live.com
=== Trying smtp.live.com:25...
=== Connected to smtp.live.com.
<- 220 BLU0-SMTP21.blu0.hotmail.com Microsoft ESMTP MAIL Service,
Version: 6.0.3790.4675 ready at Sun, 16 May 2010 14:29:18 -0700
-> EHLO dan-desktop
<- 250-BLU0-SMTP21.blu0.hotmail.com Hello [97.123.175.133]
<- 250-TURN
<- 250-SIZE 35840000
<- 250-ETRN
<- 250-PIPELINING
<- 250-DSN
<- 250-ENHANCEDSTATUSCODES
<- 250-8bitmime
<- 250-BINARYMIME
<- 250-CHUNKING
<- 250-VRFY
<- 250-TLS
<- 250-STARTTLS
<- 250 OK
-> MAIL FROM:<dan@dan-desktop>

So ... what's all this?

http://www.jetmore.org/john/code/swaks/latest/doc/ref.txt

I didn't see in the documentation above any discussion on how to
determine whether a server wants "secure authentication."

Cheers,

 

[Ilya Zakharevich]

I was "sure" that I was using SSL, and in my head it sounded right that
a secure socket layer would employ secure authentication. They are
completely separate notions.

Secure connection makes absolutely no sense without secure
authentication (well, "almost" - one can invent a FEW types of attacks
which may be stopped by "just SSL" - but why would the attackers
restrict themselves?).

The standard analogy of secure connection is sending a parcel guarded
by a policeman on route. The standard analogy of having no secure
authentication is leaving a package on a bench in a public park so
that the other party may come and pick it up. Now imagine doing
both...

So, problem solved by unchecking a box.

Hardly.

Hope this helps,
Ilya

 

[sln]

Secure connection makes absolutely no sense without secure
authentication (well, "almost" - one can invent a FEW types of attacks
which may be stopped by "just SSL" - but why would the attackers
restrict themselves?).

The standard analogy of secure connection is sending a parcel guarded
by a policeman on route. The standard analogy of having no secure
authentication is leaving a package on a bench in a public park so
that the other party may come and pick it up. Now imagine doing
both...


Hardly.

This all sounds very criminal.

-sln

 

[Peter J. Holzer]

Secure connection makes absolutely no sense without secure
authentication

I admit that I don't know exactly what "secure authentication" in SMTP
context means (haven't found a spec yet and I'm too lazy to read
Thunderbird source code (besides, it's written in C++ and off-topic in
this group )) but I do know that it is some microsoft-proprietary
authentication mechanism and probably has something to do with a domain
controller. Surely you don't think thet SSL doesn't make sense unless
you can authenticate against a Windows domain controller, do you?

If you use STARTTLS (or SSMTP), the authentication will be part of the
encrypted session and safe from eavesdropping (including MITM attacks in
a typical SUBMISSION scenario), so even PLAIN authentication is
moderately safe. CRAM-MD5 trades one weakness for another (instead of
sending a plain text passwort over an encrypted channel it is now stored
unencrypted on the server). Client-Certificates would be best but aren't
common, AFAIK.

The standard analogy of secure connection is sending a parcel guarded
by a policeman on route. The standard analogy of having no secure
authentication is leaving a package on a bench in a public park so
that the other party may come and pick it up. Now imagine doing
both...

I don't think you analogy has much to do with the situation.

hp

 

[Peter J. Holzer]

[problems authenticating at an SMTP/SUBMISSION server]

Yes. However, you don't have to write that program yourself, as somebody
has already done it: Look for "swaks" (the SWiss Army Knife for Smtp).
Some linux distributions (e.g. Debian) include it, or you can download
it from http://www.jetmore.org/john/code/swaks/

Well, hot damn:

$ swaks --to (e-mail address removed) --server pop3.live.com

=== Trying pop3.live.com:25...
*** Error connecting 0.0.0.0 to pop3.live.com:25:
*** IO::Socket::INET: connect: timeout
$ swaks --to (e-mail address removed) --server smtp.live.com
=== Trying smtp.live.com:25...
=== Connected to smtp.live.com.
<- 220 BLU0-SMTP21.blu0.hotmail.com Microsoft ESMTP MAIL Service,
Version: 6.0.3790.4675 ready at Sun, 16 May 2010 14:29:18 -0700
-> EHLO dan-desktop
<- 250-BLU0-SMTP21.blu0.hotmail.com Hello [97.123.175.133]
<- 250-TURN
<- 250-SIZE 35840000
<- 250-ETRN
<- 250-PIPELINING
<- 250-DSN
<- 250-ENHANCEDSTATUSCODES
<- 250-8bitmime
<- 250-BINARYMIME
<- 250-CHUNKING
<- 250-VRFY
<- 250-TLS
<- 250-STARTTLS
<- 250 OK
-> MAIL FROM:<dan@dan-desktop>

So ... what's all this?

If you had read the next line in the dialogue you would know:

<** 530 5.7.0 Must issue a STARTTLS command first

So you need to use STARTTLS:

% swaks --to (e-mail address removed) --server smtp.live.com --tls
=== Trying smtp.live.com:25...
[...]
<~ 250-VRFY
<~ 250-AUTH LOGIN PLAIN
<~ 250 OK
~> MAIL FROM:<[email protected]>
<~* 550 5.7.3 Requested action aborted; user not authenticated
~> QUIT

Now the server offers "AUTH LOGIN PLAIN", i.e., you can authenticate
yourself with either the LOGIN or the PLAIN mechanism. So this answers
your question:

Swaks can authenticate itself using these mechanisms, but you have to
tell it your username and password, of course.

hp

 

[Uno]

I admit that I don't know exactly what "secure authentication" in SMTP
context means (haven't found a spec yet and I'm too lazy to read
Thunderbird source code (besides, it's written in C++ and off-topic in
this group )) but I do know that it is some microsoft-proprietary
authentication mechanism and probably has something to do with a domain
controller. Surely you don't think thet SSL doesn't make sense unless
you can authenticate against a Windows domain controller, do you?

Peter,

I think this link will help:

http://www.kuro5hin.org/?op=displaystory;sid=2002/4/28/1436/66154

If you use STARTTLS (or SSMTP), the authentication will be part of the
encrypted session and safe from eavesdropping (including MITM attacks in
a typical SUBMISSION scenario), so even PLAIN authentication is
moderately safe. CRAM-MD5 trades one weakness for another (instead of
sending a plain text passwort over an encrypted channel it is now stored
unencrypted on the server). Client-Certificates would be best but aren't
common, AFAIK.



I don't think you analogy has much to do with the situation.

We can dispense with the analogies:

How Authentication Works

The NTLM authentication process uses the following algorithm:

1. Client sends NTLM Authentication Request to the server.
2. Server sends a 64-bit NTLM challenge to the client.
3. Client uses the challenge and an NTLM password hash to create an NTLM response.
4. The client sends the NTLM response to the server.
5. The server creates an NTLM response (since it also has your NTLM password hash) and compares its version with the one received by the client.
6. If the responses match, the authentication is successful.

I guess I don't know who an "attacker" is. I see movies where any
computer capability can exist, like Seth Green controlling traffic in
Los Angeles in "The Italian Job." I admire Seth's genius (Robot
Chicken), but don't think the situation possible.

What would it take for another entity to suck up all my packets that I
sent to q.com?

 

[Uno]

Yes. However, you don't have to write that program yourself, as somebody
has already done it: Look for "swaks" (the SWiss Army Knife for Smtp).
Some linux distributions (e.g. Debian) include it, or you can download
it from http://www.jetmore.org/john/code/swaks/

I appreciate the forbearance of this forum not to say "there's no perl
here" before I could get a handle on this well enough to do it with
perl, at least partially. I'm going on six months of studying unix,
which I find very consonant with studying perl syntax.

So this is what I have:

$ ./smtp1.pl
220 BLU0-SMTP57.blu0.hotmail.com Microsoft ESMTP MAIL Service, Version:
6.0.3790.4675 ready at Tue, 18 May 2010 17:27:46 -0700
$ cat smtp1.pl
#!/usr/bin/perl

use IO::Socket;
use strict;
use warnings;

my $remote_host = "smtp.live.com";
my $remote_port = "25";

my $socket = new IO::Socket::INET (PeerAddr => $remote_host,
PeerPort => $remote_port,
Proto => "tcp",
Type => SOCK_STREAM)
or die "scheisse mal\n";

print $socket "data\n";
my $line = <$socket>;

print $line;



$

q1) Can someone say a few words about the differences between the print
statements. Apparently, one sends a message to another machine, and the
other sends a message to mine.

q2) I poked around for an example listing for Programming Perl, 3rd
Edition and could not find one. Does anyone know where I might get an
electronic subset of the book I bought? Keystrokes are expensive for my
hands.

Cheers,

 

[John W. Krahn]

This one is:

print FILEHANDLE LIST



This one is:

print LIST




perldoc -f print




FILEHANDLE may be a scalar variable name, in which case the variable
contains the name of or a reference to the filehandle




If FILEHANDLE is omitted, prints by default to standard output

If FILEHANDLE is omitted, prints to the currently selected
filehandle which by default is standard output.

perldoc -f select



John

 

[Ilya Zakharevich]

I guess I don't know who an "attacker" is. I see movies where any
computer capability can exist, like Seth Green controlling traffic in
Los Angeles in "The Italian Job." I admire Seth's genius (Robot
Chicken), but don't think the situation possible.

What would it take for another entity to suck up all my packets that I
sent to q.com?

Google for it; it must be discussed out to the death. (IIRC MIB do
not need to suck up anything; all they need is to reply EARLIER than
your intended target - which is not hard given that they are IN
BETWEEN.)

Hope this helps,
Ilya

 

[sln]

Google for it; it must be discussed out to the death. (IIRC MIB do
not need to suck up anything; all they need is to reply EARLIER than
your intended target - which is not hard given that they are IN
BETWEEN.)

Such things are criminal, how are we to protect ourselves.

-sln

 

[Uno]

Such things are criminal, how are we to protect ourselves.

I like to bore them.

 

[Ilya Zakharevich]

I guess I don't know who an "attacker" is. I see movies where any
computer capability can exist, like Seth Green controlling traffic in
Los Angeles in "The Italian Job." I admire Seth's genius (Robot
Chicken), but don't think the situation possible.

In my other reply to this message, I forgot about another example with
"real life Italian Job". According to comp.risks, there exists an
available-off-the-shelf router which does exactly what people fear all
the time, but think is technically impossible:

a) this router is advertised as having something like "smart firewall";

b1) to implement this "smartness", the install program for the
router inserts a fake certificate into the trust chain which
allows the router to impersonate any site;

b2) using this "breach of authentication trust", the router DOES
impersonate all the SSL targets, and decrypts all the
communications passing through it. Then the firewall acts
basing on the decrypted contents.

Hope this helps,
Ilya

 

[Peter J. Holzer]

[This was rather off-topic to begin with and has now stopped even to
pretend to have anything to do with Perl, so I'm redirecting to
comp.security.misc]


I rarely watch movies, so I'm not familiar with the specific exploit. In
general, security holes in movies (as well as in novels) have little to
do with reality, firstly because writers know little about computers in
general and security in particular and secondly, because real exploits
would be just boring and/or confusing to the audience.

But back to the topic of STARTTLS within a SMTP/SUBMISSION session.

STARTTLS starts a TLS session, which accomplishes two things:

1) The server must authenticate itself and provide a certificate.
2) The the session is encrypted.

Additionally, client authentication is possible, but optional (and AFAIK
rarely used).

So, an attacker who sits between the client and the server (but has
access to neither), cannot decrypt the session by simple eavesdropping,
because it is encrypted.

He could intercept the packets between the client and the server and
pose as the server. To do that, he would have to present a valid
certificate which is accepted by the user. Theoretically this should be
almost impossible, but the users' wellknown disposition to click on
anything together with poor user interface design make this feasible.
It mostly depends on the user - it works only if the user is careless,
and since the SUBMISSION server changes only rarely (unlike HTTPS
servers) and needs to be specially configured, some care can be
expected.

If the attacker has compromised the server, he has access to the
unencrypted data stream and doesn't have to bother attacking TLS.

If the attacker has compromised the client, he has access to the
unencrypted data stream and doesn't have to bother attacking TLS.

In my other reply to this message, I forgot about another example with
"real life Italian Job". According to comp.risks, there exists an
available-off-the-shelf router which does exactly what people fear all
the time, but think is technically impossible:

a) this router is advertised as having something like "smart firewall";

b1) to implement this "smartness", the install program for the
router inserts a fake certificate into the trust chain which
allows the router to impersonate any site;

"the install program for the router" is the critical point here. The
attacker tricks the victim into installing malware on the client. So the
client is compromised and encrypting anything between the client and the
server is moot. The attacker could also replace the MUA with a trojaned
version. Replacing only a certificate instead of the whole software
does have the advantage of being harder to detect, but it's the same
principle.

hp