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

Hi all !

I'd like some advices about SSL and HTTPS.
Could someone tell me the difference about security between this
cases :

Let's take the yahoo mail example :

1. From a local html page on his hard drive, a user send his id/pwd
through a form like this

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

In article <1173978867.536481.206180@d57g2000hsg.googlegroups.com>,
caolla@hotmail.com wrote:

> Hi all !
>
> I'd like some advices about SSL and HTTPS.
> Could someone tell me the difference about security between this
> cases :
>
> Let's take the yahoo mail example :
>
> 1. From a local html page on his hard drive, a user send his id/pwd
> through a form like this >
> that is similar to the real one on Yahoo mail login page.
>
> 2. The same but done directly from the https yahoo site.
>
> Am I wrong if I say that case 1 is not secure ?
>
> Am I wrong if I say that before considering the transaction as secure,
> the client has to be connected first one time to the server ? This
> allows the client to check the certificate, to use it to create a
> session key that is then sent to the server ? Is this process could be
> done in case 1 ?
>
> Thanks a lot in advance !!!

You're wrong. Every HTTP or HTTPS connection is independent, and the
certificate is checked each time you make a new HTTPS connection. It
doesn't matter where you came from.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

Thank you for your answer but if so, I'd like to understand why Yahoo
mail http://edit.europe.yahoo.com/config/mail?.intl=uk (and others)
offers 2 choices : "MODE: Standard | Secure" and in the standard mode,
the form action is https.

Is that just for the users but it has no technical effects ???

Thanks in advance !

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

Post removed (X-No-Archive: yes)

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

Sebastian, you're then saying the opposite of what Barry said.

In standard mode, the current page use HTTP but the action of the
HTML form where you type your password directs you on a HTTPS page.

So, is this secure or not ? If yes, why Yahoo and others offer 2
choices that are technically identical ?

Thanks !

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

caolla@hotmail.com wrote:
> In standard mode, the current page use HTTP but the action of the
> HTML form where you type your password directs you on a HTTPS page.
> So, is this secure or not ?

If you have a well checked HTTPS connection to your password form,
_before_ you're entering a password in it, you don't need to read
the HTML source code of the page to be safe from being attacked
by a MITM.

If you don't have such a well checked HTTPS connection but plain HTTP
over TCP, then you need to check the HTML source code first each time
you're wanting to use the password form. Only then you can be sure that
there is the right target URL in the form.

Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu, die
Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)

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

Post removed (X-No-Archive: yes)

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

Post removed (X-No-Archive: yes)

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

In article <1174044557.588817.123620@y80g2000hsf.googlegroups.com>,
caolla@hotmail.com wrote:

> Thank you for your answer but if so, I'd like to understand why Yahoo
> mail http://edit.europe.yahoo.com/config/mail?.intl=uk (and others)
> offers 2 choices : "MODE: Standard | Secure" and in the standard mode,
> the form action is https.
>
> Is that just for the users but it has no technical effects ???
>
> Thanks in advance !

Lots of users are not comfortable unless they see the padlock icon
displayed by their browser. And that icon represents how the current
page was retrieved, *not* how the form will be submitted (many web pages
can submit multiple forms -- which one of them should the padlock refer
to?).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

In article <560a84F26mqr6U1@mid.dfncis.de>,
Sebastian Gottschalk wrote:

> caolla@hotmail.com wrote:
>
> > Sebastian, you're then saying the opposite of what Barry said.
>
> No, that's not the case. There's a huge difference between a website
> retrieved via HTTP and one retrieved from local storage media. That's why I
> wondered much about the OP...

But that wasn't what the OP was really asking about. He was asking
whether the encryption of the form submission depends on the form coming
from the same server as the submission. He was just using local storage
as an example of a place different from the original web site. His
concern, I suspect, was whether it would be safe for him to make a local
version of the login form for a web site (e.g. if the real web site has
an ad-laden login page, you might wish to optimize the login by making a
bare-bones local login form that has the same submission action).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

Post removed (X-No-Archive: yes)

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

Thanks to all for your answers, this is very interesting but something
still remains unclear.

If I follow Barry :

[>"He was just using local storage as an example of a place different
from the original web site. His concern, I suspect, was whether it
would be safe for him to make a local version of the login form for a
web site" : exactly, thanks Barry !]

1. Every HTTP or HTTPS connection is independent.
So, whether I enter my password from an HTML page located on my hard
disk or from an HTTP web page, since the target of the form is HTTPS,
the transaction is secure.

2. When Yahoo and others offer 2 choices, since the target is HTTPS,
the both choices are secure but though it's unjustified, the users
feel more comfortable with the padlock.

3. Volker said :
"If you have a well checked HTTPS connection to your password form,
_before_ you're entering a password in it, you don't need to read the
HTML source code of the page to be safe from being attacked by a
MITM."

This is not compatible with point 1 that says every HTTP or HTTPS
connection is independent.

My question :
Can't we be on an HTTPS web page and fill in a form for which the
target is on a HTTP web page and then making an unsecure transaction ?
If yes, it would mean (if we don't first have a look at the source
code) that we cannot be sure that the transaction is secure until we
arrive on an HTTPS web page i.e after having entered our precious
password !

Thanks again for your reactions !

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

caolla@hotmail.com wrote:
> 1. Every HTTP or HTTPS connection is independent.
> So, whether I enter my password from an HTML page located on my hard
> disk or from an HTTP web page, since the target of the form is HTTPS,
> the transaction is secure.

If it is. And you need to check the source *ANYTIME* you're using it.

> 3. Volker said :
> "If you have a well checked HTTPS connection to your password form,
> _before_ you're entering a password in it, you don't need to read the
> HTML source code of the page to be safe from being attacked by a
> MITM."
> This is not compatible with point 1 that says every HTTP or HTTPS
> connection is independent.

Wrong.

> My question :
> Can't we be on an HTTPS web page and fill in a form for which the
> target is on a HTTP web page and then making an unsecure transaction ?

Yes, this can be. Idiots do exist out there in (web)space, and they're
implementing things ;-)

> If yes, it would mean (if we don't first have a look at the source
> code) that we cannot be sure that the transaction is secure until we
> arrive on an HTTPS web page i.e after having entered our precious
> password !

You can. Just read the source, Luke!

Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu, die
Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)

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

Volker, I may misunderstand the sentence but don't you think there's a
contradiction when you sometimes say :

"If you have a well checked HTTPS connection to your password form,
_before_ you're entering a password in it, you don't need to read the
HTML source code of the page to be safe from being attacked by a
MITM."

and sometimes :

"you need to check the source *ANYTIME* you're using it."

After actions to raise public awareness about HTTPS, I'm so amazed to
discover that - if this is confirmed - we can be on a HTTPS web page
and transmit unsecure datas if the target is on a HTTP web page.

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

caolla@hotmail.com writes:

>3. Volker said :
>"If you have a well checked HTTPS connection to your password form,
>_before_ you're entering a password in it, you don't need to read the
>HTML source code of the page to be safe from being attacked by a
>MITM."

>This is not compatible with point 1 that says every HTTP or HTTPS
>connection is independent.

>My question :
>Can't we be on an HTTPS web page and fill in a form for which the
>target is on a HTTP web page and then making an unsecure transaction ?
>If yes, it would mean (if we don't first have a look at the source
>code) that we cannot be sure that the transaction is secure until we
>arrive on an HTTPS web page i.e after having entered our precious
>password !

Of course. That is why many well setup browsers will say "you are changing
to an insecure web site. All you data will be sent unencrypted. Are you
sure you want to do this" or words to that effect.



>Thanks again for your reactions !

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

caolla@hotmail.com wrote:
> Volker, I may misunderstand the sentence but don't you think there's a
> contradiction when you sometimes say :
> "If you have a well checked HTTPS connection to your password form,
> _before_ you're entering a password in it, you don't need to read the
> HTML source code of the page to be safe from being attacked by a
> MITM."
> and sometimes :
> "you need to check the source *ANYTIME* you're using it."

No, because the second sentence was in a context, that a plain HTTP
connection was used for the password form.

> After actions to raise public awareness about HTTPS, I'm so amazed to
> discover that - if this is confirmed - we can be on a HTTPS web page
> and transmit unsecure datas if the target is on a HTTP web page.

Yes, why not?

Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu, die
Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)

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

Volker, it seems you're not saying the same than others that say that
whether the page you're entering your password is on an HTTP or HTTPS
web page, it's only when you have clicked on the "send" button - or if
you've checked the code before - that you know if the datas have been
- or will be - sent encrypted or not.

Unruh, what you said is very interesting and I've checked my Firefox
settings : Show a warning dialog when I leave an encrypted page for
one that isn't encrypted is unchecked for me.
I guess I've unchecked it because I got it too many times, this is the
case for instance when you leave a secure site after you've clicked on
disconnect. If you have the option checked, you also get the warning
if for example you log on Google Groups : when you click on "sign in",
the target is fortunately on a HTTPS web page but you are then
automatically redirected on a HTTP web page and you get the warning
message.

Mozilla says for this option :

"With this option enabled, Firefox will warn you every time you move
from an encrypted page to an unencrypted page either by selecting a
link on the page, selecting a bookmark or typing a new address into
the location bar."

Then, it can be tempting to uncheck it but then one won't be warned
when sending uncrypted datas from a form on an HTTP web page to an
HTTPS one. I think there's should be a special option to warn
specifically for this, don't you think ?

But the worst thing is that the warning message don't ask you if you
want to cancel the transaction, it just warns you.
So, even if you check the option, if you don't check the code before,
you can transmit from an HTTPS web page your unencrypted password to
an HTTP web page and you know it only when it is done ! Incredible !

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

caolla@hotmail.com wrote:
> Volker, it seems you're not saying the same than others that say that
> whether the page you're entering your password is on an HTTP or HTTPS
> web page, it's only when you have clicked on the "send" button - or if
> you've checked the code before - that you know if the datas have been
> - or will be - sent encrypted or not.

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

Clear now?

Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu, die
Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)

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

Volker Birk 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
> assiduously.

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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

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

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

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:
http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#40 PKI: The terrorists's secret weapon
http://www.garlic.com/~lynn/aadsm26.htm#41 PKI: The terrorists's secret weapon (part II)

lots of other posts mentioning MITM attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

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.
http://www.garlic.com/~lynn/x959.html#x959

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
http://www.garlic.com/~lynn/2001h.html#61

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

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).
http://www.garlic.com/~lynn/subpubkey.html#catch22

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
http://www.garlic.com/~lynn/subpubkey.html#certless

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

In article <1174139740.255978.82000@d57g2000hsg.googlegroups.com>,
caolla@hotmail.com wrote:

> Thanks to all for your answers, this is very interesting but something
> still remains unclear.
>
> If I follow Barry :
>
> [>"He was just using local storage as an example of a place different
> from the original web site. His concern, I suspect, was whether it
> would be safe for him to make a local version of the login form for a
> web site" : exactly, thanks Barry !]
>
> 1. Every HTTP or HTTPS connection is independent.
> So, whether I enter my password from an HTML page located on my hard
> disk or from an HTTP web page, since the target of the form is HTTPS,
> the transaction is secure.
>
> 2. When Yahoo and others offer 2 choices, since the target is HTTPS,
> the both choices are secure but though it's unjustified, the users
> feel more comfortable with the padlock.
>
> 3. Volker said :
> "If you have a well checked HTTPS connection to your password form,
> _before_ you're entering a password in it, you don't need to read the
> HTML source code of the page to be safe from being attacked by a
> MITM."
>
> This is not compatible with point 1 that says every HTTP or HTTPS
> connection is independent.

I think his point is that someone could have intercepted the HTTP
connection and modified the form so that it submits the password to
their server instead of the real server.

So this does somewhat correct what I said before. If you go to the form
and you get a certificate warning, you need to be careful. But if the
form is accessed with HTTP, there won't be a warning -- you'd have to
read the HTML source to be sure that your password will be submitted to
the correct place.

>
> My question :
> Can't we be on an HTTPS web page and fill in a form for which the
> target is on a HTTP web page and then making an unsecure transaction ?
> If yes, it would mean (if we don't first have a look at the source
> code) that we cannot be sure that the transaction is secure until we
> arrive on an HTTPS web page i.e after having entered our precious
> password !

While it's possible, it's very unlikely. Why would a company offer a
secure connection for downloading the form, but not for submitting it,
when the latter is where the private information is?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

Post removed (X-No-Archive: yes)

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

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

All is clear now.
I first misunderstood some of you and I was mainly focusing on the
second responsibility.
Thanks all !