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.
formatting link
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.
formatting link
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:
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
Did you take a look at the screenshot? It has the Opera logo to give you the hint.
Which still does not happen until after YOU have entered the login credentials and when YOU send them.
For a web-based forum? We're talking about a web-based *forum*. None of their content is secret, personally private, or secure. It's anyone talking to anyone and none of whom are legally identified. HTTPS is a waste of resources for PUBLIC information.
HTTPS does attempt but not guarantee that the domain you intended to visit is the one from where you received a web page. So that is better than securing the credentials on the send operation. Of course, anyone that installs a root cert on your host can do a MITM attack no matter to where you visit whether HTTP or HTTPS. That's how anti-virus software can inspect your HTTPS traffic looking for malicious content. That's how streaming video capture software works for media from HTTPS sites. That's how your employer can monitor your HTTPS traffic.
Why would I recognize every logo or chrome style of every web browser? The OP should have identified his web browser instead of making viewers guess at it.
So, for you to actually help the *OP*, answer the inquiry: Does Opera have a safe mode? If so, tell the OP how to use it for testing.
Web forums are often attacked. Many people use the same password repeatedly on many sites, so they attack one, then try those login/pass obtained on other more interesting places.
As the page has a javascript to get your credential, it do not need to wait for a post, it can send as soon as both login/password are off focus.
The MitM-attack will not go unnoticed if you use HTTPS.
You know how often people uses the same credentials on more than one site, in theory it could be the same as the bank site credentials.
The certificate is bound to a domain and the certificate is verifiable by the CA, so you can be pretty you are requesting data from the same domain as the certificate or you will be notified, which should make you aware that there is something wrong.
Exception is self signed, they will just give you an encrypted connection, without knowing the domain is really the one you want to visit.
This requires you to get the root certificate installed at first, over HTTP you don't need a root certificate and the user has no way to detect the attack.
Yes, there are a lot of bad software which does bad things, but that do not mean you should ignore best practice, what you should do is avoid using those applications which do decrease the security of your operating system.
Most people I know do recognize the logo, could be something to do with it's been a popular mobile browser and got some traction with the built in VPN support on the desktop version.
I did NOT say the login credentials were sent via HTTP. Those are hashed up using some "md5hash" named function which I did not bother to see to where it sent those hashed up strings. The web page can be HTTP but the web form submit could be to an HTTPS target. The login is protecting the user's account, not protecting the content of the forum.
MotorsForum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.