Re: Can SSL sessions be compromised?

"Powercat" <powercat@xxxxxxxxxxx> 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 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

also, various countermeasures to SSL (and other protocol)
vulnerabilities may result in catch-22 for certification authority

and posts mentioning various kinds of mitm-attacks

for some additional information ... our rfc index

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.