Re: Bank of America - On Line Banking *NOT* Secure?

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 06/25/05 

Date: 25 Jun 2005 15:24:21 -0600

"John E. Hadstate" <jh113355@hotmail.com> writes:
> You can still connect to https://www.bankofamerica.com/ but they
> immediately redirect you to http://www.bankofamerica.com/. From a
> cursory examination of the Javascript, it looks like the login
> information is submitted using an https connection to a cgi
> application.

Originally, SSL was supposed to be countermeasure for two
vulnerabilities

1) spoofed website and/or MITM attack
2) evesdropping

there have been mechanisms that allow key exchange that don't require
certificates & CAs ... that then would allow encrypted sessions as
countermeasure for evesdropping.

the SSL domain name certificates were supposed to provide that the
domain name that you typed in for the URL ... matched the domain name
provided in an SSL domain name certificate (from the server)
http://www.garlic.com/~lynn/subpubkey.html#sslcert
and subsequently leveraged to provide key exchange with the valid
end-point and end-to-end encryption.

the problem was that a lot of merchants ... considering the original
SSL target for e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

... found that they got something like five-times the thruput using
non-SSL. The result is that the merchants avoided using SSL & https
for non-evesdropping scenarios ... reserving it solely for
evesdropping like operations. in the e-commerce scenario, that
typically met the user got to entually click on a "check-out" or "pay"
button, which, in turn invoked SSL for the payment phase.

the problem was that the URL the user provided was never checked
against the certificate of the site the user was visiting. So if the
user happened to be dealing with a spoofed site ... when they finally
got to the "pay" button ... the "pay" button generated a URL (on the
user's behalf) and if it happened to be a spoofed site, it was highly
likely that the URL that the spoofed site provided as part of the
"pay" button, was highly likely to match whatever was in an SSL domain
name certificate from the server that the user had been directed to.

the issue is that if there really is a spoofed site vulnerability and
that the user might happen to be visiting a spoofed site (which is in
large part the justification for SSL, ssl domain name certificates,
certification authorities, etc) ... then nothing the spoofed site does
or provides should be trusted ... including any javascript or other
html related stuff that invokes ssl (as a evesdropping countermeasure)
... since it may also be to another fraudulent site (and they are
keeping the other crooks from evesdropping on their spoofed
communication).

spoofed site technology can either be straight spoofed site ... its
own site with all its own files providing the look & feel of the real
site. A spoofed site might also be done as man-in-the-middle attack
... where the spoofed site is actually acting as a middle man between
the end-user and the real site ... although possibly subtly modifying
communication passing thru:
http://www.garlic.com/~lynn/subpubkey.html#mitm 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/