Re: Is that secure : <form action="https" from a local HTML page ?

Volker Birk <bumens@xxxxxxxxxxx> writes:
I don't understand what you're complaining.

Encryption has *TWO* responsibilities here:

- the encrypted transport (via TLS, HTTPS) of the form itself makes you
safe from getting a compromized version, which was modified by a MITM

- the encrypted form POST makes you safe from an attacker getting your
password data by being MITM

Of course, both only will work, if you're checking certificates

the original assumption in SLL was that the person typed in the URL
(knowing the relationship between the webserver and the URL). The
browser then validated that the webserver contacted was the webserver
for that URL (via checking for a valid domain name certificate and the
domain name in the URL corresponded to the domain name in the
certificate) ... aka the webserver you think you are talking to is
actually the webserver you are talking to is actually the webserver
you think you are talking (you knew the connection between the
webserver and the URL, the browser validated the connection between
the webserver's URL and the webserver's domain name certificate).

this was quickly subverted by most electronic commerce deployments
when they discovered that using SSL cut their thruput/performance
by 80-90 percent ... a couple past post mentioning consulting for
a small client/server startup that wanted to process payments on
their servers ... they had this technology called SSL and it needed
to be applied to real business processes ... it frequently is now
referred to as electronic commerce

the default became you typed in (non-https) URL and did all your
shopping online (no MITM countermeasure) and then the webserver
provided a button that you clicked on that got you an SSL connection
to the payment process. Since the individual no longer had any
awareness of the relationship between the URL and the payment webset
.... and no longer provided the URL ... the subsequent certificate
checking was only validating that the website had a valid
certificate. The scenario about the website that you thought you were
talking to is actually the website you are talking to was broken. The
only thing now being proven was that the website corresponded to the
website URL that the website claimed to be. lots of past posts about
SSL domain name certificates (many referring to early days of SSL
deployments and original assumptions)

A bogus MITM-website could be handling all the shopping (since that
part wasn't being checked) ... and then it handed it off to a bogus
"payment" URL (for some website that the attackers were able to obtain
a valid certificate). Again, the whole scenario about are you really
talking to the website that you thot you were talking to ... has been

Later email phishing took advantage of this same disconnect by having
people click on a URL in the phishing email. The email claimed that
the URL was for something else than what the URL actually was
(i.e. original SSL assumption based on the person knowing the
connection between the website and the URL was circumvented). The
attackers could have the provided URL be an SSL connection to a
website for which they had a valid certificate (since the browser is
only checking the correspondance between the domain name in the
provided URL and the domain name in the certificate).

Bascially SSL was designed as MITM countermeasure to ip-address
hijacking and/or stuff like DNS cache poisoning (attacking the
correspondance/mapping between a domain name and an ip-address). To
actually have SSL serve as a generalized MITM countermeasure required
that the user know the correspondance between the website/URL that
they thot they were talking to and the website/URL they actually were
actually talking to. When that was lost ... lots of attacks were
possible in the infrastructure. An MITM-attacker could even provide a
valid SSL URL (via email) for connection to their website ... which
then transparently established a second SSL connection to the "real"

The problem with phishing using bogus impersonation websites
(regardless of whether SSL was used or not) become prevalent enuf to
justify some institutions looking at other countermeasures to website
impersonation (i.e. additional website identification mechanisms so
the user had additional confidence that the website they thot they
were talking to, was actually the website they were talking
to). However, these mechanisms typically didn't have any
countermeasures to MITM-attacks ... aka phishing pointed to a MITM,
bogus website that transparently created a connection to the "real
website". some posts in recent threads touching on the subject: EV - what was the reason, again? man in the middle, SSL man in the middle, SSL man in the middle, SSL man in the middle, SSL man in the middle, SSL PKI: The terrorists's secret weapon PKI: The terrorists's secret weapon (part II)

lots of other posts mentioning MITM attacks

so after consulting for this small client/server startup (that had this
technology they called SSL) on what was to be called electronic
commerce, we spent some time in the x9a10 financial standard working
group. In the mid-90s, the x9a10 financial standard working group had
been given the requirement to preserve the integrity of the financial
infrastructure for all retail transactions. the result was the x9.59
financial standard.

x9.59 transactions now have end-to-end authentication "armoring" ... as
countermeasure to attackers using any information (from a previous
transaction in replay attacks) for generating new, fraudulent
transactions. This eliminates the risk of evesdropping/replay attacks
.... and therefor there is no pressing need to actually encrypt the
transaction and/or hiding the information during transmission (which
is the current major, wide-spread electronic commerce use for SSL in
the world today). The x9.59 standard also eliminates the risk in the
majority of the data breaches and security breaches where the
attackers are able to turn around and use the information to generate
fraudulent transactions (it doesn't eliminate such data breaches and
security breaches, it just makes most of the information useless to
the attackers ... eliminating majority of the financial motivation for
the bad guys for performing the breaches). some topic drift about
security proportional to risk around many of the breaches

this somewhat involves the security acronym "PAIN"

P - privacy (or sometimes CAIN, confidental)
A - authentication
I - integrity
N - non-repudiation

.... in effect, X9.59 is using end-to-end authentication and integrity
(transaction armoring) as a countermeasure to fraudulent financial
transactions ... in lieu of SSL's "privacy" (which is only
hiding/encryting the information during internet transmission).

now, SSL countermeasures to MITM vulnerabilities have other issues.

the typical business process for a domain name SSL certificate has the
applicant providing a lot of identification information. Nominal the
certification authority (before generating the certificate) is
supposed to perform the (time-consuming, error prone, and expensive)
task of matching the applicant's identification information with the
identification information on file with the domain name information
(for the real domain name owner). Since the root fundamentals of the
whole infrastructure is then dependent on the validity of this
information (at the domain name infrastructure); things like domain
name hijacking (where the domain name ownership information is
modified) ... throws a big vulnerability into the whole infrastructure
(i.e. attacker perform domain name hijacking using a bogus corporation
under the attacker's control ... and then applies for an ssl

So there are some proposals (even backed by the certification
authority industry) for improving the integrity of domain name
infrastructure operation. This also creates something of a dilemma,
since a large part of the justification for SSL (in the first place)
involved their bieng integrity issues/problems with the domain name
infrastructure. Fixing some number of these integrity issues,
significantly reduces the justification for having SSL (certificates).

Even more than a dilemma, there is a real catch-22. Part of the
integrity improvements and countermeasure for domain name hijacking
has the domain name owner registering a public key as part of
ownership. Then all future communication is digital signed (and the
digial signature validated with the on-file public key, NOTE no
digital certificates are involved). This eliminates some amount of
unauthorized, bogus communication perporting to transfer domain name
ownership (reducing the risk of domain name hijacking).

The certification authority industry can even can make use of this
feature and require SSL domain name certificate applications to be
digitally signed. Then the certication authority can replace the
error-prone, time-consuming, complex and possibly very expensive
identification matching process with a much more reliable, simpler,
and less-expensive authentication process (by also doing real-time
retrival of the on-file public key from the domain name infrastructure
to validate the applicant's digital signature).

The catch-22 is that if the certification authority industry can start
making use of (and base their whole business on) real-time retrieval
of public keys (from the domain name infrastructure) ... then it is
possible that the rest of the world could also start doing real-time
retrieval of public keys ... totally eliminating the requirement for
SSL domain name digital certificates (and the certification authority
industry). misc. past posts mentioning this catch-22 for the
certification authority industry (end-users getting information
directly from the authoritative agency responsible for the information
.... rather than going thru the certificaton authority intermediary).

There is even the possibility of a new, highly optimized SSL-like
protocol using domain name infrastructure real-time public keys
.... and no digital certificates. misc. past posts mentioning public
key operation w/o requiring the use of digital certificates