How do you handle unencrypted web sites even with https encryption?

I'm just curious how you handle logging into unencrypted web sites even
when the site itself has encryption?
http://wetakepic.com/images/2017/07/04/site.jpg

You don't need a login to test this - you just need to type one letter in
the login field to see what I explain below.
http://wetakepic.com/images/2017/07/04/site3.jpg

But why?

When I go to this URL it says my login credentials are not secu
http://www.toyota-4runner.org

So I go to this URL instead but it says the same thing for login!
http://www.toyota-4runner.org

And when I try, I get an "invalid redirect URL" error.
http://wetakepic.com/images/2017/07/04/site3.jpg

Can someone explain why and what you would do if you want to log in?

On Wed, 5 Jul 2017 08:51:19 +0900, ATANARJUAT wrote
I n response to ATANARJUAT >

> When I go to this URL it says my login credentials are not secu
> http://www.toyota-4runner.org
>
> So I go to this URL instead but it says the same thing for login!
> http://www.toyota-4runner.org

Oh oh I do typo!
The second url is supposed to have an "s" on it.

First url says the login is not secu http://www.toyota-4runner.org
Second url says the login is not secu https://www.toyota-4runner.org

Can anyone explain why?

ATANARJUAT wrote:

> I'm just curious how you handle logging into unencrypted web sites even
> when the site itself has encryption?
> http://wetakepic.com/images/2017/07/04/site.jpg

Either the page is encrypted or it is not. You cannot have it both
ways. Any HTTP site can navigate or redirect you to an HTTPS page.

Also, just because a page is delivered via HTTP doesn't mean a web form
submission is also sent via HTTP. The submit action of a web form
designates to where the data gets sent. If it points at an HTTPS page
then the input you entered locally in your web browser gets sent to the
HTTPS page. That means the delivery page for login input might be HTTP
but the login credentials get sent using HTTPS. So the login is still
protected.

From what you show in your pic, you were obviously moved from an HTTP
page to an HTTPS page to enter your login credentials. So what is your
concern? The login page is an HTTPS page.

> You don't need a login to test this - you just need to type one letter in
> the login field to see what I explain below.
> http://wetakepic.com/images/2017/07/04/site3.jpg

www.toyoto-4runner.org is not a Toyota domain. Whomever registered that
domain is hiding behind a private domain registration. IANA demands
that valid contact information be listed for a domain registration.
Registrars can usurp that responsibility by listing themself as the
domain registrant (which is a lie). This lets the real registrant hide
behind the registrar pretending to be the domain registrant. The
registrar charges extra for this privacy service.

https://www.whois.com/whois/toyota-4runner.org

Entering an characters in the username and password fields does not
update the page from HTTP to HTTPS.

What I see in the HTTP page source is:

<form action="http://www.toyota-4runner.org/login.php?do=login"
method="post" onsubmit="md5hash(vb_login_password, vb_login_md5password,
vb_login_md5password_utf, 0)">

So that page takes the input field (I only saw they putzing with the
password) and hashes it up using their md5hash function. When I hit the
Login button, I'm taken to an HTTPS page. I didn't bother to dig into
their md5hash function but it is likely where they send their hashed
input data to an HTTPS page.

Note that I do not allow scripts, by default, from off-domain sources.
Their login page does use scripts and some of them are off-domain.
That's probably why when I start entering characters into the input
fields that nothing happens. I did not bother to investigate all their
off-domain sources. The only that I temporarily enabled was Google's
ajax script library (ajax.googleapis.com). I didn't bother to see if
enabling scripts from viglink.com would make their page interactive
(since you indicate just entering any character into the input fields
changes the page from HTTP to HTTPS - but if it did that then you would
lose everything you typed in the HTTP page when redirected to their
HTTPS page).

> But why?
>
> When I go to this URL it says my login credentials are not secu
> http://www.toyota-4runner.org

Doesn't matter if the page is delivered via HTTP or HTTPS to you. A
site doesn't need to encrypt your login credentials because they aren't
the ones sending that data. Only when YOU send that data do you want it
encrypted. The site could redirect you to an HTTPS page to do the
login. The site can specify the submit action of a web form send the
data (still local to you) to an HTTPS page, so that connection is
encrypted.

I could not get the interactive switch from HTTP to HTTPS that you
indicate just by entering some characters into the input fields.
Doesn't seem like that would work, anyway. When they switched, you
would lose whatever you already entered and have to reenter it.

> So I go to this URL instead but it says the same thing for login!
> http://www.toyota-4runner.org
>
> And when I try, I get an "invalid redirect URL" error.
> http://wetakepic.com/images/2017/07/04/site3.jpg

You have to use the landing page that THEY support. Don't make up your
own landing pages. Their HTTPS page may not work with their md5hash
function to do the submit to what is the actual HTTPS submit page.

> Can someone explain why and what you would do if you want to log in?

What complete URL does the *site* tell you to use for their home landing
page? Do they specify http:// or https://?

If this is the result of using the HTTPS Everywhere login, it has
problems with sites that demand you land on an HTTP page and they will
take care of encrypting your login credentials when those are actually
*sent* by your client.

ATANARJUAT wrote:

> ATANARJUAT:
>
>> ATANARJUAT:
>>
>> When I go to this URL it says my login credentials are not secu
>> http://www.toyota-4runner.org
>>
>> So I go to this URL instead but it says the same thing for login!
>> http://www.toyota-4runner.org
>
> Oh oh I do typo!
> The second url is supposed to have an "s" on it.
>
> First url says the login is not secu http://www.toyota-4runner.org
> Second url says the login is not secu https://www.toyota-4runner.org
>
> Can anyone explain why?

Are you using a secret web browser? I cannot tell from the tab bar what
is the web browser you took a screen snapshot. Opera maybe?

Both URLs work fine in my config of Google Chrome 59.0.3071.115 and
Firefox 54.0 (both are the 64-bit versions); however, I'm on Windows 7
at home where I replied.

On 07/05/17 01:51, ATANARJUAT wrote:
> I'm just curious how you handle logging into unencrypted web sites even
> when the site itself has encryption?
> http://wetakepic.com/images/2017/07/04/site.jpg
>
> You don't need a login to test this - you just need to type one letter in
> the login field to see what I explain below.
> http://wetakepic.com/images/2017/07/04/site3.jpg
>
> But why?
>
> When I go to this URL it says my login credentials are not secu
> http://www.toyota-4runner.org
>
> So I go to this URL instead but it says the same thing for login!
> https://www.toyota-4runner.org

A large part of the content will always be sent over http, this includes
images, scripts loaded, when you request for a https page which gets
also content over plain http the connection will be classed as unsecure,
as it's easier to affect the data sent over http by a third party which
could lead to that the credentials could be stolen by a rouge script.


> And when I try, I get an "invalid redirect URL" error.
> http://wetakepic.com/images/2017/07/04/site3.jpg
>
> Can someone explain why and what you would do if you want to log in?

Just guessing, there is some configuration error on the redirect back to
the forums first page after the login, which makes Opera to throw an error.

You could use the Network Inspector built in Opera to take a close look
on the response you got.

--

//Aho

In rec.autos.tech, on Tue, 4 Jul 2017 22:44:36 -0500, VanguardLH
> wrote:

>ATANARJUAT wrote:
>
>> ATANARJUAT:
>>
>>> ATANARJUAT:
>>>
>>> When I go to this URL it says my login credentials are not secu
>>> http://www.toyota-4runner.org
>>>
>>> So I go to this URL instead but it says the same thing for login!
>>> http://www.toyota-4runner.org
>>
>> Oh oh I do typo!
>> The second url is supposed to have an "s" on it.
>>
>> First url says the login is not secu http://www.toyota-4runner.org
>> Second url says the login is not secu https://www.toyota-4runner.org
>>
>> Can anyone explain why?
>
>Are you using a secret web browser? I cannot tell from the tab bar what
>is the web browser you took a screen snapshot. Opera maybe?
>
>Both URLs work fine in my config of Google Chrome 59.0.3071.115 and
>Firefox 54.0 (both are the 64-bit versions); however, I'm on Windows 7
>at home where I replied.

You're actually using 64-bit Firefox? When I got 64-bit Windows 10, I
tried that and it barely worked at all. when I asked about this,
someone told me it wouldn't work well. Does it maybe work better with
win7 than win10 (win10 as it was last summer.)

As to his results using FF54.0.1 when I just entered toyota-4runner.org,
the page came up and www was added in front, but nothing more. All I
had to do was put the cursor in the login field and I got the warning he
talks about.

So I added http:// and it was the same.
And I added https:// and the page looked the same afail, but the warning
no longer showed up even after typing a letter in that field.

What all this menas, I don't know, just more data points. Except I don't
think there is a problem, and even if there were, what does it matter if
hacker logs into a car forum in someone else's name anyhow? When money
is involved, people are directed to secure sites.

In rec.autos.tech, on Wed, 5 Jul 2017 08:55:12 +0900, ATANARJUAT
> wrote:

>On Wed, 5 Jul 2017 08:51:19 +0900, ATANARJUAT wrote
>I n response to ATANARJUAT >
>
>> When I go to this URL it says my login credentials are not secu
>> http://www.toyota-4runner.org
>>
>> So I go to this URL instead but it says the same thing for login!
>> http://www.toyota-4runner.org
>
>Oh oh I do typo!
>The second url is supposed to have an "s" on it.
>
>First url says the login is not secu http://www.toyota-4runner.org
>Second url says the login is not secu https://www.toyota-4runner.org

Doesn't say that for me for the second one. FF54.0.1
>
>Can anyone explain why?

micky wrote:

> VanguardLH wrote:
>
>> Both URLs work fine in my config of Google Chrome 59.0.3071.115 and
>> Firefox 54.0 (both are the 64-bit versions); however, I'm on Windows
>> 7 at home where I replied. ^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^ /
\_________________________________________________/
/
/
> You're actually using 64-bit Firefox? When I got 64-bit Windows 10,
> I tried that and it barely worked at all. when I asked about this,
> someone told me it wouldn't work well.

I cannot address what some unknown "someone" told you. Did you actually
inquire over in the Firefox newsgroup (mozilla.support.firefox on
news.mozilla.org, port 119)? I'm not bothering with Windows 10 until I
am forced to use it and that's not likely at home. I am forced on a few
lab workstations at work but I use the sysprep image for a constant
baseline for testing.

I cannot address "worked at all" or "wouldn't work well". Too vague.
See you over in the Firefox newsgroup. Add details. 64-bit Firefox was
released Dec 2015. If there was a problem using Firefox in Windows 10,
I would have seen a big and continued stink about that in the Firefox
newsgroup.

> Does it maybe work better with win7 than win10 (win10 as it was last
> summer.)
>
> As to his results using FF54.0.1 when I just entered toyota-4runner.org,
> the page came up and www was added in front, but nothing more.

www is the hostname. When you connect to a site, you connect to a host,
not to a domain. The nameserver can default to a hostname. www is
usually the default

> All I
> had to do was put the cursor in the login field and I got the warning he
> talks about.

Perhaps due to one of the myriad of other off-domain scripts that I do
not permit to run. I may try a few that look relevant to a site but if
they demand using a suspicious domain for a script then I don't allow it
with perhaps the effect the site won't function.

However, WITHOUT the automatic scripted input check, I was able to enter
a username and password and click on the Login button. Since I don't
have an account there, obviously the login failed (no such user) but the
input form still worked. So the script is superfluous.

> So I added http:// and it was the same. And I added https:// and the
> page looked the same afail, but the warning no longer showed up even
> after typing a letter in that field.
>
> What all this menas, I don't know, just more data points. Except I
> don't think there is a problem, and even if there were, what does it
> matter if hacker logs into a car forum in someone else's name anyhow?
> When money is involved, people are directed to secure sites.

No money involved. It is a web-based peer forum. Nothing of its
content needs to be encrypted (so HTTPS is a waste of resources). Only
the login credentials need to be protected.

If loading the web browser in its safe mode (disabling all add-ons)
doesn't work, then I'd next try resetting the web browser or create and
use a new profile in that client. If that still doesn't work, reboot
Windows into its safe mode with networking and retest.

The site doesn't provide any site statistics. So, for example, you
wouldn't know if it was undergoing maintenance. Could be they are
changing the site's setup and were clumsy in the migration; i.e., they
might still have old pages that aren't supposed to be used but did not
update a redirection table to go to the new pages or missed some so the
pages are mixed between old and new. They could be experimenting. No
information about the duration of the problem means not knowing if this
is a transient effect.

They have a Contact Us link at the bottom of their web page. Unlike a
lot of web-based forums that force you to login and use your account to
contact an admin, this one uses e-mail (it's a mailto link).

J.O. Aho wrote:

> On 07/05/17 01:51, ATANARJUAT wrote:
>> I'm just curious how you handle logging into unencrypted web sites even
>> when the site itself has encryption?
>> http://wetakepic.com/images/2017/07/04/site.jpg
>>
>> You don't need a login to test this - you just need to type one letter in
>> the login field to see what I explain below.
>> http://wetakepic.com/images/2017/07/04/site3.jpg
>>
>> But why?
>>
>> When I go to this URL it says my login credentials are not secu
>> http://www.toyota-4runner.org
>>
>> So I go to this URL instead but it says the same thing for login!
>> https://www.toyota-4runner.org
>
> A large part of the content will always be sent over http, this includes
> images, scripts loaded, when you request for a https page which gets
> also content over plain http the connection will be classed as unsecure,
> as it's easier to affect the data sent over http by a third party which
> could lead to that the credentials could be stolen by a rouge script.

Mixed content (HTTP content sent over a presumably HTTPS connection) may
occur but only if the web browser permits the insecure page. Either a
web page is secure or not secure. There is no in between. Any HTTP
content means the HTTPS connection is insecure. Often the mixed content
is from off-domain sources, like ads although sometimes it can be for
scripts, too. Yeah, I know some users think, gee, images are okay to be
sent via HTTP on what should be an HTTPS page but that's not true.
Images can convey personal or sensitive information. For example, a
site can overlay an image (and flatten it to deliver an image file) used
as a background with your accounting information. Retrieving images
from off-domain sources also allows for tracking which is a privacy
issue for many users.

Internet Explorer had settings to control mixed content a long LONG time
ago, like nearly 2 decades ago. It took Mozilla over a decade to catch
up but their default is to allow passive mixed content (images);
however, that can be changed in its settings. Google Chrome gives you
no such choice; i.e., Chrome is far less configurable than Firefox.
Chrome uses Firefox's default of allowing passive HTTP content over an
HTTPS connection. So whether or not mixed content is allowed depends on
the web browser and how it is configured. Not all users will permit
delivery of an insecure web page over a supposedly secure connection.

Protection of login credentials is only an issue when *sending* them
from your client to the target host. Nothing needs to be secured for
the page delivered to you because obviously that page doesn't pre-load
your login credentials. If it did, there would be no point in requiring
you to validate your identify via login. Only when you send your login
credentials should they be encrypted. An HTTP login page can be
delivered to you but the web form's submit action can direct that output
data to an HTTPS target, so the login is protected. This site uses some
"md5hash" function to locally modify the entered login credentials. I
did not bother to see to where that function sends the credential info.

>> And when I try, I get an "invalid redirect URL" error.
>> http://wetakepic.com/images/2017/07/04/site3.jpg
>>
>> Can someone explain why and what you would do if you want to log in?
>
> Just guessing, there is some configuration error on the redirect back to
> the forums first page after the login, which makes Opera to throw an error.

Is it Opera that the OP is using? The OP never mentioned which web
browser he is using nor mentioned trying another web browser. The OP
should try running his web browser in its safe mode to eliminate
interference by add-ons. For example, I found the HTTPS Everywhere
add-on (when I trialed it) to cause LOTS of problems at numerous sites.
Simply redirecting the connection from http:// to https:// doesn't
always work, especially at sites that expect that they will redirect
your initial connection when appropriate.

On 07/05/17 18:22, VanguardLH wrote:

> Protection of login credentials is only an issue when *sending* them
> from your client to the target host. Nothing needs to be secured for
> the page delivered to you because obviously that page doesn't pre-load
> your login credentials.

How are you sure that the insecurely page sent do not come from a
man-in-the-middle attack which has injected credential stealing javascript?

The page from which the credentials are posted should be sent over HTTPS
or the login is counted as insecure even if you post if over HTTPS to
the receiving page.


> If it did, there would be no point in requiring
> you to validate your identify via login. Only when you send your login
> credentials should they be encrypted. An HTTP login page can be
> delivered to you but the web form's submit action can direct that output
> data to an HTTPS target, so the login is protected. This site uses some
> "md5hash" function to locally modify the entered login credentials. I
> did not bother to see to where that function sends the credential info.
>
>>> And when I try, I get an "invalid redirect URL" error.
>>> http://wetakepic.com/images/2017/07/04/site3.jpg
>>>
>>> Can someone explain why and what you would do if you want to log in?
>>
>> Just guessing, there is some configuration error on the redirect back to
>> the forums first page after the login, which makes Opera to throw an error.
>
> Is it Opera that the OP is using? The OP never mentioned which web
> browser he is using nor mentioned trying another web browser.

Did you take a look at the screenshot? It has the Opera logo to give you
the hint.


--

//Aho