@IanMacdonald. You were told a few times that you do not understand what HTTPs is for and how it works, and i can see you have not made an effort to learn and keep posting things that have nothing to do with HTTPs.
@IanMacdonald. You were told a few times that you do not understand what HTTPs is for and how it works, and i can see you have not made an effort to learn and keep posting things that have nothing to do with HTTPs.
HTTPS is a functional product when used as intended. What is being done here, is that in the interests of profit it's being promoted for use in situations where it will not function effectively. Yet, the public are not being told of this. They are being told that it will prevent MITM attacks. It will only prevent a subset of such attacks.
They are being told that it will certify the origin of the data. It is only capable of certifying the content of ONE data source on a site. (Which in practice is the least likely source to be malicious)
The greatest documented and proven vuln is passwords being stored as plaintext, and HTTPS does NOT protect against this.
The blog topic is disabling of products. And, yes, Google and Mozilla have announced intentions to disable an increasing number of HTML, CSS and media features where the site does not use HTTPS. That is bricking.
Also Bud, I find your attitude unacceptable. I have spent a good deal of time investigating this, and you think you can just 'tell' me that someone else has told you otherwise? Have you done any tests yourself, on the issues I have raised? I would hazard a guess as no.
HTTPS is a functional product when used as intended. What is being done here, is that in the interests of profit it's being
promoted for use in situations where it will not function effectively. Yet, the public are not being told of this. They are being told that it will prevent MITM attacks. It will only prevent a subset of such attacks.
They are being told that it will certify the origin of the data. It is only capable of certifying the content of ONE data source on a site. (Which in practice is the least likely source to be malicious) So, it does not do what it is claimed to.
The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.
The fix to HTTPS isn't simple. For the site visitor faced with a malfunctioning browser, the fix is to stop using Chrome or Firefox, I guess. Which might happen. For the website owner it involves either paying for a certificate and jumping through all kinds of technical hoops installing it, or else using Lets Encrypt, in which case you will be renewing the damn thing over and over like crazy. Forget, and your site goes down. Neither is a good solution.
If MITM attacks by ISPs are taking place in the wild, show me documented proof of them. And, not just a single example.
The elephant in the room here, which I've mentioned time and time again, is that you don't have to have mixed content on a page any more for it to be insecure. Before this nonsense started, a hacker would have had to convince a certificate issuer to issue a cert for 'ebsy.com' or 'amaxon.com' to make it look secure, and likely the issuer would have refused.
The point I'm making here is that we are implementing security against a low level and largely unproven threat at the expense of blowing away the security where security matters. Those who can't see this, need to get their heads out of their *******.
Typosquatting has never been prevented effectively by SSL.
Typosquatting has never been prevented effectively by SSL.And now that unsecured connections will begin getting flagged, I expect we'll see normal SSL losing even more "visibility", with a greater focus on enhanced validation certs for anyone doing Important Things.
Typosquatting has never been prevented effectively by SSL.Proper SSL does protect against typosquatting, because if a human is involved in the certificate issuing process they will likely smell a rat and refuse. A robot issues the cert regardless.
ebsy.com can be registered and have an SSL cert issued (morally and technically) by East Bay Soccer Youth or anyone else with a desire to have ebsy.com.
ebsy.com can be registered and have an SSL cert issued (morally and technically) by East Bay Soccer Youth or anyone else with a desire to have ebsy.com.Do you think the human registrar could type that into a browser and notice that it has the Ebay trademark top left instead of a soccer ball? I think they could.
Also Bud, I find your attitude unacceptable. I have spent a good deal of time investigating this, and you think you can just 'tell' me that someone else has told you otherwise? Have you done any tests yourself, on the issues I have raised? I would hazard a guess as no.
HTTPS only works properly on sites with a single data source.