Re: Can SSL sessions be compromised?



"Powercat" <powercat@xxxxxxxxxxx> writes:
Hello I hope someone will take the time to answer my question. I'm
with a contractor inside someone else's facility. The facility allows
us to use their computers for internet access to our headquarters. We
communicate with HQ via browser-based sessions ("webmail") and this is
via SSL (https) connections. Sometimes we transmit documents (Word,
PDF, etc) attachments using webmail during these SSL sessions.

one of the most common SSL compromises has to do with various kinds of
man-in-the-middle attacks at session startup (as opposed to evesdropping
and/or man-in-the-middle after session is up and running).

the issue is weakness in various setups having to do with SSL startup
and whether the client is checking to see whether the server is actually
who the client thinks the server is ... or the process has degenerated
into the client just checking that the server is who the server claims
to be.

part of this has to do with the fundamental digital certificate and PKI
paradigm ... i.e. the trusted distribution of information in an offline
environment ... and the client can have some level of trust that the
information in the digital certificate is valid. the issue is that an
attacker may have a perfectly valid digital certificate with perfectly
valid information ... it is just not the information that the client
expects it to be. what is happening is that some client processes will
just check for valid information (i.e. valid digital certificate) ...
as opposed to valid information exactly matching some predefined
requirement. when clients are (effectively) just checking for any valid
information ... then a MITM-attack involves setting up a intermediate
SSL session (impersonating the server to the client) and then setting up
a second intermediate SSL session (impersonating the client to the
server).

lots of past posts about SSL certificates (including some number of
methods for attacks/compromises)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

i.e. long ago and far away ... we had been called into consult
with this small client/server startup that wanted to do payments
on their servers ... a couple old posts
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology that they called SSL ... and we had to do some
transformation from technology to business process and also detailed
vulnerability and threat analysis.

one of the countermeasures is to preload into the client ... the exact
information that the client application has to expect (and make sure
that the information in any presented digital certificate exactly
matches). however, this countermeasure violates the basic assumptions
under which digital certificates, certification authorities, and PKI
paradigms are justified and makes the digital certificates redundant and
superfluous.

If the countermeasure involves preloading the exact server information
(for matching against information in digital certificate) ... then it is
obvious that the preloaded information could be the server's public key
.... in which case it is no longer necessary to have a digital
certificate. With the client already having the server's public key,
then it would be possible to have a highly optimized SSL operation with
much of the current SSL session protocol setup chatter eliminated.

various past posts specifically discussing various SSL vulnerabilities
and the "catch-22" for the certification authority industry with some of
the countermeasures that result in making the digital certificates
and PKI infrastructure redundant and superfluous
http://www.garlic.com/~lynn/subpubkey.html#catch22

.