Prev: FAQ 5.4 How do I delete the last N lines from a file?
Next: FAQ 4.61 How can I always keep my hash sorted?
From: Peter J. Holzer on 25 May 2010 11:04
[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(a)ilyaz.org> wrote:
> On 2010-05-19, Uno <merrilljensen(a)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
First  |  Prev  | 
Pages: 1 2 3 4
Prev: FAQ 5.4 How do I delete the last N lines from a file?
Next: FAQ 4.61 How can I always keep my hash sorted?