Go Back   Wireless and Wifi Forums > News > Newsgroups > comp.security.misc
Register FAQ Forum Rules Members List Calendar Search Today's Posts Advertise Mark Forums Read

 
Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 05-25-2010, 03:04 PM
Peter J. Holzer
Guest
 
Posts: n/a
Default Re: determining whether a server supports secure authentication

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

On 2010-05-25 06:07, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-05-19, Uno <merrilljensen@q.com> wrote:
>> 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.


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

Reply With Quote
  #2 (permalink)  
Old 05-26-2010, 03:58 AM
Ilya Zakharevich
Guest
 
Posts: n/a
Default Re: determining whether a server supports secure authentication

On 2010-05-25, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:

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


A (minor) correction: IIRC, nothing is REPLACED. Just a teeny-weeny
new certificate is installed[*]. That is all that is needed to
completely break the chain of trust...

Yours,
Ilya
[*] Reminds me my first weeks after switching to ADSL. Things "just
did not work right". I spent about 12 hours experimenting with
combinations of filters and/or switching on/off devices on the
phone line, and speaking with technicians on the phone. What they
say would be "This just can't happen."

During the home visit, the technician fixed it in 15 minutes. All
he needed to do was to "remove a teeny-weeny box from the
phoneline outside the house". Do not know whether it was me who
was a target, or a previous resident...

Reply With Quote
  #3 (permalink)  
Old 05-26-2010, 09:05 PM
Peter J. Holzer
Guest
 
Posts: n/a
Default Re: determining whether a server supports secure authentication

On 2010-05-26 03:58, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-05-25, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>
>>> 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.

>
> A (minor) correction: IIRC, nothing is REPLACED.


1) I wrote that the attacker COULD replace the MUA, not that he did.
He could also replace your OS or flash your BIOS. Once your machine
is compromised you can't trust it any more (if you ever could).

2) Something is replaced: The list of trusted CAs (the new list has one
additional entry).

hp


Reply With Quote
Reply


« Extended deadline (15 July 2010): CACS Singapore [EICompendex,ISTP,IEEE Xplore] | Upcoming USENIX CFP Deadlines: WOOT, HotDep, SLAML, and More »
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
https question not_here.5.species8350@xoxy.net comp.security.misc 3 11-28-2008 03:10 PM
Problem with Netgear WGPS606 wireless print server communicating with BT Home Hub ecm200 Network Troubleshooting 2 02-27-2008 01:08 PM
Authentication Open vs Shared Key Bob Simon comp.security.misc 5 09-14-2007 10:10 AM
"Proper" server v powerful PC Jase alt.comp.hardware 16 08-21-2005 05:53 PM
[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1 Shannon Appel comp.security.misc 0 07-31-2005 04:25 AM


All times are GMT. The time now is 02:20 AM.



Powered by vBulletin® Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.6.0 PL2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45