Can SSL sessions be compromised?

Can SSL sessions be compromised?
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Can SSL sessions be compromised? Powercat 04-01-2007
Posted by Powercat on April 1, 2007, 10:15 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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.

All of this flows through the facility's proxy servers. They have
several "detective" programs running.

We don't have anything to hide but I'm wondering how much of this they
can see???

I do get "intrusion detected" messages but we think that's because the
IP address of the computer I use is different than the IP address of
the proxy machine -- if I enable local cookies for authentication this
goes away.

Thanks.


Posted by Volker Birk on April 1, 2007, 11:21 am
If you were  Registered and logged in, you could reply and use other advanced thread options
[TLS]
> We don't have anything to hide but I'm wondering how much of this they
> can see???
> I do get "intrusion detected" messages but we think that's because the
> IP address of the computer I use is different than the IP address of
> the proxy machine

They see everything.

Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu,
die Bevölkerung zu manipulieren."
        (Dr. Daniele Ganser, 2005)
<http://www.auchdieserschwachsinnmussinsinternet.de/>

Posted by Anne & Lynn Wheeler on April 1, 2007, 11:48 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> 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


Posted by Ertugrul Soeylemez on April 1, 2007, 3:02 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

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

Depends on the endpoints of the SSL connection. If the endpoint is the
proxy server, then be aware that they can read everything. SSL protects
the connection, not the data. It makes sure that nobody is listening,
and it makes sure that you are really talking to the person you've been
intended to talk to.

Protecting the data itself would mean encrypting and authenticating it,
which should be done independently of SSL.


> All of this flows through the facility's proxy servers. They have
> several "detective" programs running.

If your endpoint is your HQ server, then there is still the possibility
that they can read everything. This happens, if the SSL connection is
not authenticated. The HQ server should have either a validated
certificate (i.e. signed by a trustcenter) or a known certificate
(i.e. self-signed, but the other party has a copy of the certificate).


> We don't have anything to hide but I'm wondering how much of this they
> can see???
>
> I do get "intrusion detected" messages but we think that's because the
> IP address of the computer I use is different than the IP address of
> the proxy machine -- if I enable local cookies for authentication this
> goes away.

No. This is really an intrusion. The proxy server tries to break the
SSL connections with an MITM attack. Otherwise you wouldn't get a
warning at all.


Regards,
Ertugrul S=C3=B6ylemez.


--=20
=46rom the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.

Posted by Anne & Lynn Wheeler on April 1, 2007, 4:41 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> I do get "intrusion detected" messages but we think that's because the
> IP address of the computer I use is different than the IP address of
> the proxy machine -- if I enable local cookies for authentication this
> goes away.

your "SSL server" machine may be trying to catch some simple types of
client MITM ... by checking the origin IP-adddress that it sees against
the IP-address that the application on your computer knows about. If the
corporate gateway (between internal corporate operation and the
internet) is using NAT ... then the "SSL server" will be dealing with
the "NAT ip-address" ... not your local client machine ip-address.

part of the issue is that most standard SSL deployments are not doing
mutual authentication ... i.e. the client is using SSL to supposedly
authenticate the server ... but there isn't an equivalent "mutual" SSL
authentication of the client (by the server). As a result, the "SSL
server" is probably attempting to validate/authenticate clients via
other mechanisms ... possibly including various mechanisms where
authentication information is squirreled away in cookies (and not
finding that, falling back to other things, including checking for
inconsistent ip-addresses)

in the early SSL stuff that we were doing for what has since come
to be called electronic commerce
http://www.garlic.com/~lynn/2007g.html#32 Can SSL sessions be compromised?

we eventually mandated SSL mutual authentication between the commerce
servers and the payment gateway (this was before there was a
specification and code for mutual authentication) ... we actually
mandated a number of other implementation details, attempting
to compensate for standard internet environment not really have
been developed with business critical dataprocessing in mind.

in any case, it was during this deployment that we also realized that
for online environments and/or environments where there was existing
relationship between the two entties ... digital certificates and PKI
with certification authorities (CAs) were redundant and superfluous.

There had to be pre-registration and installation of each merchant with
the payment gateway ... and the payment gateway preregistered with each
merchant. In effect, we pre-installed the trusted infromation (& public
key) of each at the other's respective site(s). The traffic flow
continued to look like standard defined SSL protocol ... with all the
extraneous digital certificate protocol chatter ... only because they
wanted to (re-)use the existing software library that they had already
done (that only had support for certificate-based operation) ... aka the
(trusted) information carried by the digital certificates was
essentially meaningless ... since as part of the standard business
relationship process ... the (trusted) information was required to
pre-exist at the respective endpoints.

as before ... lots of past posts mentioning ssl and ssl digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

also, various countermeasures to SSL (and other protocol)
vulnerabilities may result in catch-22 for certification authority
industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

and posts mentioning various kinds of mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

for some additional information ... our rfc index
http://www.garlic.com/~lynn/rfcietff.htm

and select "Term (term->RFC#)" in the "RFCs listed by" section

then select "NAT" in the acronym fastpath ... i.e.

network address translation
4787 4380 4008 3947 3715 3519 3489 3424 3235 3105 3104 3103 3102
3027 3022 2993 2766 2709 2694 2663 2428 2391 1631

clicking on any RFC number, brings up that RFC in the lower RFC summary
(frame). clicking on the ".txt=nnn" field (in the RFC summary) retrieves
that RFC.

Similar ThreadsPosted
Videos/animations for InfoSec sessions April 6, 2008, 3:22 am
Securew2 compromised -- anyone have more info? October 30, 2006, 9:55 am
Compromised email accounts May 21, 2008, 6:00 pm
28,000 Sailors Compromised. Lt. Cole - All is Not Secure! June 27, 2006, 1:14 pm
SSL security with server certificate compromised December 22, 2006, 7:06 am

The site map in XML format XML site map

Contact Us | Privacy Policy