From: Peter J. Holzer on
On 2010-05-16 23:08, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2010-05-16, Uno <merrilljensen(a)q.com> wrote:
>> 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

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
From: Peter J. Holzer on
On 2010-05-16 21:43, Uno <merrilljensen(a)q.com> wrote:
> On 5/16/2010 6:20 AM, Peter J. Holzer wrote:
>> On 2010-05-16 05:09, Uno<merrilljensen(a)q.com> wrote:

[problems authenticating at an SMTP/SUBMISSION server]


>>> 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/
>
> Well, hot damn:
>
>> $ swaks --to merrilljensen(a)q.com --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 merrilljensen(a)q.com --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(a)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 merrilljensen(a)q.com --server smtp.live.com --tls
=== Trying smtp.live.com:25...
[...]
<~ 250-VRFY
<~ 250-AUTH LOGIN PLAIN
<~ 250 OK
~> MAIL FROM:<hjp(a)zeno.hjp.at>
<~* 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:

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

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

hp
From: Uno on
Peter J. Holzer wrote:
> On 2010-05-16 23:08, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
>> On 2010-05-16, Uno <merrilljensen(a)q.com> wrote:
>>> 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
>
> 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.
>
>
>> 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.

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
From: Uno on
Peter J. Holzer wrote:

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

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,
--
Uno
From: Tad McClellan on
Uno <merrilljensen(a)q.com> wrote:

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


This one is:

print FILEHANDLE LIST


> my $line = <$socket>;
>
> print $line;

This one is:

print LIST


> q1) Can someone say a few words about the differences between the print
> statements.


perldoc -f print


> Apparently, one sends a message to another machine,


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


> and the
> other sends a message to mine.


If FILEHANDLE is omitted, prints by default to standard output


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.