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

J.O. Aho wrote:

> 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?

Which still does not happen until after YOU have entered the login
credentials and when YOU send them.

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

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.

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

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.

On 2017-07-05 21:53, VanguardLH wrote:
> J.O. Aho wrote:

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

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.

--
Cheers, Carlos.

On 07/05/17 21:53, VanguardLH wrote:
> J.O. Aho wrote:
>
>> 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?
>
> Which still does not happen until after YOU have entered the login
> credentials and when YOU send them.

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.


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

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.


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

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.

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

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.


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

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.


>> Did you take a look at the screenshot? It has the Opera logo to give you
>> the hint.
>
> 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.

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.


--

//Aho

Carlos E.R. wrote:

> VanguardLH wrote:
>
>> J.O. Aho wrote:
>
>>> 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.
>>
>> 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.
>
> 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.

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.

"J.O. Aho" > writes:
> On 07/05/17 21:53, VanguardLH wrote:
>> 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.
>
> The certificate is bound to a domain and the certificate is verifiable
> by the CA,

Certificates are issued by CAs, not verified by them. They are verified
by the endpoints to the communication (the browser, in this case).

--
http://www.greenend.org.uk/rjk/

In alt.comp.os.windows-10 VanguardLH > wrote:
> Carlos E.R. wrote:
>
>> VanguardLH wrote:
>>
>>> J.O. Aho wrote:
>>
>>>> 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.
>>>
>>> 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.
>>
>> 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.
>
> 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.

The point is that when the form is served via HTTP it could be modified
in transit to add code that would steal your credentials as you
input them into the form. It doesn't matter that the form would submit
to an HTTPS site. You credentials would be stolen (in this scenerio)
before you hit the submit button.

When parts of a page are served via HTTP, you cannot guarantee that
other parts of that page (even when served over HTTPS) have not been
modified. That is the reality of the way the web works.