Can SSL sessions be compromised?

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.

Re: Can SSL sessions be compromised?

Powercat wrote:
[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)

Re: Can SSL sessions be compromised?

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

Re: Can SSL sessions be compromised?

"Powercat" (07-04-01 07:15:58):

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


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

Re: Can SSL sessions be compromised?

"Powercat" writes:
> 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.

Re: Can SSL sessions be compromised?

SSL is a very weak system using encryption that can be cracked in real
time by anyone with the knowledge and just a couple of thousand US $

It should never be trusted for things like banking etc.
Its use is to keep out hobby hackers and determined hobby hackers.
It is not capable of protecting against determined organised attack.

Re: Can SSL sessions be compromised?

buy@answers.com writes:

> SSL is a very weak system using encryption that can be cracked in real
> time by anyone with the knowledge and just a couple of thousand US $
>
> It should never be trusted for things like banking etc.
> Its use is to keep out hobby hackers and determined hobby hackers.
> It is not capable of protecting against determined organised attack.

Specify a version level of SSL (greater than known-weak SSL v 2.0)
that this applies to, or a specific implementation's flaw, cite
resources, or step away from the crackpipe and/or troll keyboard.



Best Regards,
--
Todd H.
http://www.toddh.net/

Re: Can SSL sessions be compromised?

Post removed (X-No-Archive: yes)

Re: Can SSL sessions be compromised?

comphelp@toddh.net (Todd H.) writes:
> Specify a version level of SSL (greater than known-weak SSL v 2.0)
> that this applies to, or a specific implementation's flaw, cite

re:
http://www.garlic.com/~lynn/2007g.html#32 Can SSL sessions be compromised?
http://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?

SSL is suppose to do two things ... 1) are you really talking to the
webserver that you think you are talking to and 2) hide/encrypt
information during transmission.

the attacks that I'm aware have been with regard to the first item
.... including allowing various kinds of MITM-attacks (as mentioned
in previous posts).

recent post about MITM-attack
http://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks make the news

as well blog discussion

THREATWATCH: MITB SPOTTED: MITM OVER SSL FROM WITHIN THE BROWSER
https://financialcryptography.com/mt/archives/000884.html

Re: Can SSL sessions be compromised?

Anne & Lynn Wheeler writes:

> comphelp@toddh.net (Todd H.) writes:
> > Specify a version level of SSL (greater than known-weak SSL v 2.0)
> > that this applies to, or a specific implementation's flaw, cite
>
> re:
> http://www.garlic.com/~lynn/2007g.html#32 Can SSL sessions be compromised?
> http://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
>
> SSL is suppose to do two things ... 1) are you really talking to the
> webserver that you think you are talking to and 2) hide/encrypt
> information during transmission.
>
> the attacks that I'm aware have been with regard to the first item
> ... including allowing various kinds of MITM-attacks (as mentioned
> in previous posts).
>
> recent post about MITM-attack
> http://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks make the news
>
> as well blog discussion
>
> THREATWATCH: MITB SPOTTED: MITM OVER SSL FROM WITHIN THE BROWSER
> https://financialcryptography.com/mt/archives/000884.html

MITM, is indeed relatively simple with SSL.

The silly post I replied which you trimmed implied weakness in the
encryption, which if it actually exists must be a compromise that is
very tightly held.

Best Regards,
--
Todd H.
http://www.toddh.net/

Re: Can SSL sessions be compromised?

comphelp@toddh.net (Todd H.) writes:
> MITM, is indeed relatively simple with SSL.
>
> The silly post I replied which you trimmed implied weakness in the
> encryption, which if it actually exists must be a compromise that is
> very tightly held.

re:
http://www.garlic.com/~lynn/2007g.html#32 Can SSL sessions be compromised?
http://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
http://www.garlic.com/~lynn/2007g.html#58 Can SSL sessions be compromised?

note that SSL is fairly, large, complex, expensive infrastructure to
deploy with the certification authorities, PKIs, digital certificates,
etc ... all primarily addressed at the part of SSL directed at
preventing things like MITM-attacks.

the encryption part, by comparison, is much more reliable and trusted.
however, there are much simpler and less expensive ways to do such
encryption (if you weren't trying for MITM countermeasures).

to make the situation even more interesting ... there have been numerous
discussions about the period when SSL was introduced ... that there
actually hadn't been any known fraud from evesdropping attacks
(listening to unencrypted transmissions) ... but there numerous
situations where fraud resulted in all kinds of end-point attacks and
MITM-attacks.

as a result, the evesdropping countermeausres (i.e. the encryption) was
possibly the least needed ... while the MITM and end-point protections
were the most needed. The additional, very expensive and very complexity
in SSL was in large part justified as being countermeasures to the much
more prevalent vulnerabilities (not the encryption for the evesdropping
countermeasures).

however, all that additional complexity and very expensive
infrastructure appears to have provided little additional security in
the form of effective countermeasures to numerous kinds of MITM and
end-point attacks.

i would contend that the encryption part of SSL is by far and away the
more secure part of SSL ... and also possibly the least needed ... in
terms of countermeasures to prevalent attacks (before the introduction
of SSL).

the counter argument is that once SSL had been deployed ... that since
the encrypted/transmission part has by far and away the highest level of
security ... that then the attackers go after the weakest points ... the
MITM and end-point attacks

lots of past posts mentioning SSL
http://www.garlic.com/~lynn/subpubkey.html#sslcert

Re: Can SSL sessions be compromised?

comphelp@toddh.net (Todd H.) (07-04-06 10:15:49):

> > SSL is a very weak system using encryption that can be cracked in
> > real time by anyone with the knowledge and just a couple of thousand
> > US $
> >
> > It should never be trusted for things like banking etc. Its use is
> > to keep out hobby hackers and determined hobby hackers. It is not
> > capable of protecting against determined organised attack.
>
> Specify a version level of SSL (greater than known-weak SSL v 2.0)
> that this applies to, or a specific implementation's flaw, cite
> resources, or step away from the crackpipe and/or troll keyboard.

There is one implementation-specific flaw that some implementations
(especially in browsers) use RC4 by default. Also I wouldn't consider
the default key lengths secure enough. There is nothing specifically
broken here, but I can't recommend RC4 for new applications.

These design decisions are based on the fact that strong cryptography
takes CPU power. It's not SSL's fault, and luckily you can always turn
from the defaults.


Regards,
Ertugrul Söylemez.


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

Re: Can SSL sessions be compromised?

Post removed (X-No-Archive: yes)

Re: Can SSL sessions be compromised?

In article ,
thesimple@truthis.com wrote:
>
>
>You dont even need technical skills to know for certain that SSL is not now nor will it ever be secure.
>
>The US government demands that it is only implemented with very weak methodologies specifically
>for the reason that it can then be hacked by them whenever they want.

I think you're a paranoid netkook, but I'll give you a chance. What are the
weak methodologies the US is forcing people to use, and how can they be
cracked? Be specific, please. Evidence on how the US is forcing people
to use these methods would be nice as well.
>
>If they can do so then so can anyone else.
>
>Anyone spouting technical waffle to pretend otherwise is an idiot.
>There is no secret about this.
>
Then you should have no problems providing evidence.


--
Christopher Mattern

NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities