Chrome is warning users about insecure pages
certsimple.com
certsimple.com
> A proposal then is to do HTTPS everywhere in the sense of the protocol but not the URI prefix. A browser gives the secure-looking user interface message, such as displaying the server certificate holder name above the document, only when the document has been fetched in an authenticated over an encrypted channel. This can be done by upgrading the HTTP to include TLS in real time, or in future cases by just trying encrypted version first.
He also states
> It is the user's task to ensure that their interactions are secure.
meaning, users are trained to look for the 's' but browsers are hiding the URI prefix, making this difficult.
Ideally, we should be using DANE or some other kind of signed broadcasted info. Telling the user what happened is just a very good workaround (that will stay useful even if we change to DANE).
Right, I think his point there was, the ecosystem has to make many changes to ensure the links are the "secure version": we create URLs with https, make browser changes to redirect (HSTS), use redirect in server software, etc.
With "just" HTTP, all URLs are uniform, but the protocol is modified upon connection to 'upgrade' the link to something secure, instead. HSTS maybe wouldn't be needed (or would take a slightly different form).
Maybe browsers should stop with that idiocy then.
They don't understand that when someone says "go to google.com" that something isn't wrong when the url bar says "https://google.com". They think they something is broken.
Heck, Safari now be default doesn't even show you the path, they just show the domain, because once people get to foo.com they don't even understand about the paths, nor care.
You don't need to learn about the Dewey decimal system when reading books, either. For the same reason - it's helpful for finding things, it allows you to classify books, and it doesn't matter at all since there are better ways to find books now.
While I agree, I do not believe this is an appropriate excuse for ignorance (I am not accusing you of anything, just criticizing the viewpoint itself).
Computers are part of life. People know about antibiotics, vaccine, stem cells, black holes, and they know atomic radiation causes cancer and the same material can be used for atomic bombs, about wavelengths, and certain ones (UV) cause cancer by breaking DNA, etc.
But, not technology? How is there such a well-formed ignorance when it comes to technology? It's fed to us by the media too, who cite "computer glitches"[1,2,3] when something goes wrong, or when there is a breach of the system and all credentials stolen.
And, not understanding URLs leads to susceptibility to information being stolen from phishing attacks. Whose "fault" is there here?
[1] "Glitch" http://money.cnn.com/2013/12/26/news/companies/delta-ticket-...
[2] "Something broke" https://www.theguardian.com/technology/2016/feb/08/departmen...
[3] "Glitch" http://www.nbcnews.com/video/nightly-news/48088061
Browser developers aren't in a position to retrain users to their preferred ideology. Their job is to find ways to make the web easier to use.
And in fact they have: green URL bars, padlocks etc. – these are UI metaphors that do a much better job than a one-letter change in a cryptic initialism from the 70'ies.
Even holier-than-thou professionals should profit from this: a green URL actually means the connection is protected, whereas it's quite easy to use https without actually using encryption or at least using completely insecure ciphers.
First, browsers added a padlock icon on the left for https:// sites. Then, phishing sites, and even banking websites, started using a padlock for their favicon, and users couldn't tell the difference. So it was abandoned.
Then, the whole background of the URL bar was turned a sort of gold-yellow color when the site was secure. It was like this: http://www.facebookloginhut.com/wp-content/uploads/2010/07/s...
Then that effect was removed, I think it scared some users, or they didn't know to look for it, I don't know.
Now, favicons are never shown in the URL bar so a padlock favicon can no longer mislead. Some browser started hiding "http://", some started coloring "https://". (Now many do both.) The extended-validation green pill thing was added. It's harder than ever to allow a self-signed cert when you're using a service you set up yourself on your LAN.
Apparently there are more changes planned, every year or so. "users" have no chance of keeping this stuff straight, only "experts" like me and you do.
I wouldn't worry as much about how to get people to notice security, browser vendors are on the right track by popping up giant notices for insecure sites and sites with malware.
They just need to extend the "untrusted download" concept from operating systems to email where you could have "untrusted link" warnings in your browser instead. "Are you sure you want to visit paypal.28753272.server? You really shouldn't trust this link..."
And yet https://support.squarespace.com/hc/en-us/articles/205815898-...
Even amazon.com serves over https now...
Hey all -- it's actively being worked on and will arrive soon. As someone on this thread correctly pointed out, it's a complex implementation due to how our infrastructure is set up.
We run a cpanel server and have a let's encrypt plugin that allows users to generate and install their own certificates.
We currently do not have the power to change the behavior or the market share of these hosting companies in any significant way. That leaves working around their behavior as the option.
Check out Lego project, it makes DNS Auth very easy :)
Competition can only kick in when browsers go crazy about plain text etc.
As I said, there are easy steps clients can use to make their provider care. But if the clients themselves don't care, nobody will.
Article from 2010: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
The absolute cheapest I've found one of those for is $95 a year. So basically, more than all of my server hosting, my domain hosting, and my domain privacy combined, all to sign my CSR that has a one-character change in it.
Of course, if you want both yourdomain.com and www.yourdomain.com (because just *.yourdomain.com won't match the former), then that will, of course, cost extra. A lot extra.
I really can't for the life of me understand why they won't offer a wildcard certificate, if you prove you are the owner of the base domain name. The cynic in me expects it's the same reason every CA in existence charges four to ten times more for a wildcard certificate that literally costs them nothing more to make. That entire market would vanish overnight if Let's Encrypt offered them for free. I would even immediately start using them for my site.
In terms of policy, wildcards encourage some users to both reuse the same certificate for multiple services (i.e. mail, website, api, etc.), and use certificates that are "broader" than needed (use wildcards everywhere because they're "easier", despite the fact that you only need a certificate for imap.example.com). This increases the impact of Heartbleed-like vulnerabilities significantly (in that unrelated services using the same key are suddenly all vulnerable to MitM attacks). It might not be the worst idea to give the ecosystem some time to get used to non-wildcard certificates in order to discourage that behaviour.
I think there's a good chance we'll see wildcard support sooner or later.
But yeah I do hope you're right. I'll switch my domain off self-signing the moment a trusted CA offers a free wildcard cert with elliptic curve signing.
I don't see why that would be a problem, given that one of the main points of Let's Encrypt is that it can be automated.
This is despite the fact they previously made money from selling certificates, and still will take your money for doing so if you want.
(Not an employee, just a satisfied customer who now has free HTTPS hosting etc..)
(All in all, a satisfied customer also, but I ran to the Two-Factor Authentication setup in the panel as soon as I found this out.)
When something many people/companies do/use/have feels hard or out of reach, I think it's important to start asking different questions and look around for real solutions.
For the sake of an example https://www.cloudflare.com/ isn't exactly hard, and is free.
All I use it for is my Jekyll-powered personal site on GitHub pages. I don't mind not using GitHub for it anymore, just want it to work with SSL.
You can do this wile still maintaining Namecheap as your registrar, and it's totally free.
For instance, I'll bet that if you set it up so that your namecheap DNS A entry was pointed to your own box that had nginx/haproxy/cloudflare/whatever handling SSL decryption (and certs) and then backended to your github pages, it would work, but I'm not a fan of the idea.
Namecheap even goes a step further and has an API for domain validation (makes LE certificate authorization easier) so they are very friendly in regards to Let's Encrypt.
> Today Chrome's stable channel was updated with a new HTTPS UI.
But I remember noticing these changes at least a week ago if not longer. The Chrome Stable channel link he used supports me in this as it's dated July 20, 2016.
If I'm being phished by organized crime, I'd still rather the NSA not also be able to listen in.
The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means.
All you're doing, then, is attempting to replace a heavily vetted, non-MITMable identity-verification scheme with your own ad-hoc version of the same, and what the security community understands is that you're incredibly likely to fuck this up in a way that makes it trivial for your attacker to forge their identity.
If I'm on an unsecured wireless network at the local Starbucks, untrusted TLS means I know nobody else in the coffee shop is snooping on it or injecting anything into it.
Why is this so difficult for people to grasp?
Security involve both a technical and social aspect. While the unsigned cert may offer better security (but there is no way for you to know) it most certainly offers a worse social aspect, that being a false sense of security.
So I'd say you're wrong -- it is strictly worse, because it offers no better security but a worse sense of security.
That Starbucks access point you've connected to might actually be the Pineapple belonging to the guy at the corner table, and he's injecting his own untrusted SSL certs into your HTTPS traffic and snooping/injecting into all your traffic.
EDIT - and to clarify what others have said: HTTPS implies a trusted connection (unlike plain HTTP). And a self-signed certificate cannot be trusted under any circumstances.
Your only protection would be if you pre-installed said self-signed certificate before going to the coffee shop. Your warning would be that the certificate was suddenly untrusted again.
It also wouldn't prevent an attack by someone that could forge a certificate from a trusted intermediate CA. HPKP could help there; but if you have someone like that targeting you in a coffee shop, you have much bigger problems.
The important thing though is that this is still not worse than plain HTTP. And in fact, it's better: it makes the attacker's job a lot more difficult. Especially when done at large scale (eg ISP ad injection.)
Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings.
Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth.
Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.)
DNSSEC+DANE would also help, but again, that'd also reduce reliance on the CA system, so don't expect that to ever happen.
Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there.
"We don't want anyone spying on you! ... unless it's your school, workplace, or laptop vendor (eg Lenovo.)"
> Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth.
There's a massive difference between "anyone can MitM this connection" and "a small number of nation-state actors might be able to MitM this connection if you do not implement HPKP." A system that prevent such mis-issuance events from staying secret (Certificate Transparency) is also being worked on and is picking up speed.
> Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.)
AFAIK all browsers except Safari support name constraints.
> Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there.
This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
So what's next? Browsers begin refusing all connections to sites which aren't pinning their keys and using a CA doing transparency? How much of the web do we have to shut off and force into ludicrously-insecure plaintext connections before people start to get that maybe there's room for a spectrum of options here?
Certificate Transparency is required for some CAs (with known mis-issuance events) in Chrome, and I expect it will become mandatory for all publicly-trusted CAs within the next couple of years. I doubt this would affect custom (internal) CAs.
I'm not sure I understand the rest of your argument.
I agree completely. But the parent poster said "not-MitMable", which was false. It's more difficult, but the CA system has quite a lot of flaws. Even HPKP isn't a total solution: there's still the initial connection. I don't think there's an HPKP browser built-in solution like with HSTS yet. DANE would be the better option here -- we could reduce the number of trusted authorities from 2,000+ down to ~5 or so. At least enough that we don't have to have CNNIC when we reside in the US.
Further, HPKP scares me. It requires you to keep a secondary key, but if something happens like a fire, you could lose both keys. Not everyone is going to make duplicate backups of certificate keys and store them in bank vaults or doubly encrypted cloud storage locations or something. Especially not for small-time personal websites. Combine it with HSTS and really long max-age values and someone can get themselves into a world of pain quite easily.
> AFAIK all browsers except Safari support name constraints.
Oh, that's encouraging! When I read up on it, I found "The Name Constraints extension is mostly unsupported by existing implementations of SSL. They are likely to ignore the extension." And I know it tends to take browsers several years to support anything related to security (see Firefox's open bug for Curve25519 for the past three years; how many years it took us to get AES256-GCM cipher support [still not in Firefox 48 but will be in 50]; etc.)
So then, perhaps we can petition browser makers to allow self-signed certificate installations to be less terrifying/complicated when they are name constrained to just the domain in question? Yeah, didn't think so.
> This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
You're right that once someone has administrator access, it's game over. But you could at least make their lives more difficult: force their hand into compiling a hacked up version of your browser that bypasses HPKP. That would discourage a lot of casual workplace snooping (you'd have to block users from installing browers/browser updates, too.)
The real objection I have is that right now, browsers say, "yes this connection is totally safe and secure!", even though it's actually not. You're being MiTM'ed by your employer/school/etc. If the fear of self-signed certificates is a false sense of security, then surely this is much worse since you even see the green lock.
There are plenty of stories about employers snooping on SSL traffic, and their employees being stunned/unaware their employers are doing it.
You're free to outsource the risk of losing key access by pinning to a small number of CAs you trust (and possibly have a business relationship with) instead of keys under your control. You're already willing to trust at least a small number of organizations for DANE, so you might as well do the same for HPKP.
> So then, perhaps we can petition browser makers to allow self-signed certificate installations to be less terrifying/complicated when they are name constrained to just the domain in question? Yeah, didn't think so.
How is it complicated? Firefox has a simple UI where you can import certificate files in the trust store (I just counted - it's < 10 clicks). Other browsers typically use the OS trust store, to which you can add certificates by just opening a pem/pfx file and following a few steps in a wizard. For the group of users that I'd trust to make reasonable decisions when they're facing a certificate warning, you can't honestly tell me that this would be an obstacle.
> But you could at least make their lives more difficult: force their hand into compiling a hacked up version of your browser that bypasses HPKP.
Or in other words, give users a false sense of privacy, which you're never going to get on a device that's controlled by someone else.
You're also ignoring the fact that this could be a hindrance to HPKP deployment, as users that visit sites that deploy HPKP would see warnings and possibly be scared off, meaning the site might lose visitors initially. That's typically a good way to make sure no one adopts a protocol. I'd rather have a protocol that does not attempt to solve an impossible problem than one that doesn't see any real-life usage.
BUT PLAINTEXT ALSO ALLOWS THAT, and in addition allows eavesdropping and alteration by another middleman.
Imagine that today I visit https://example.com and I see a certificate from a CA that I trust. Everything is good: my browser shows a lock icon. Tomorrow (or a year from now), I visit again, and a malicious state actor intercepts the TCP session and returns a certificate that's self-signed or from a CA I don't trust. What should the user experience be?
It definitely shouldn't be exactly the same as the trusted cert from example.com! It shouldn't be trusted at all. The behavior where the untrusted certificate shows up as "bad" protects me from MITM -- the difference between trusted and untrusted is the protection. Even though self-signed certs are in some sense better than plaintext, treating them that way will compromise the security of path-validated certs: any degree of trust creates a risk that they'll be substituted for CA-signed certs and trick a user into continuing.
In a world where there are only plaintext and self-signed certs, I'd agree that self-signed are better and should be allowed. But in a world with path-validated certs, accepting and trusting self-signed certs has downsides. HSTS helps with this but isn't a complete solution.
Your comment would be better without the "bangs head on desk" and caps expressing your frustration. https://news.ycombinator.com/newsguidelines.html
If you really think sites should never be MITM-able, then you should complain just as loudly on a plaintext site as you do on an untrusted root.
If I go to gmail I'd like to get a warning instead of accidentally not noticing there is no lock indicator in my browser.
If you're arguing for opportunistic encryption for "http://" links, I'm fine with that, but if I'm expecting HTTPS, I want either a trusted certificate or a big, red warning that's hard (or impossible) to bypass. I'm also not convinced that opportunistic encryption is worth the effort nowadays, given that the price of a certificate is zero in all but the most obscure of use-cases.
They do care about someone casually sniffing the password to the blog's admin interface when they post from a coffeeshop, though. But for years -- it's only recently that viable zero-dollar browser-trusted certs became a possibility -- we told those people "screw you, you're so dangerous for wanting that, we have to produce the loudest, nastiest, most terror-inducing popup warnings we can come up with just to slap on your disgustingly evil site and shame you into paying hundreds of dollars to a corrupt cartel".
Which confuses the poor schmuck who just wants that little bit of security against that particular, but far more common than MITM, threat model. De-conflating the two concerns -- inability to eavesdrop, and inability to impersonate -- might not be such a bad idea for those people.
You can argue for opportunistic encryption in HTTP, but I'd argue that it's cheaper and easier for most affected parties if browser vendors just help push the price of publicly-trusted certificates to zero, which is exactly what Mozilla and Chrome (among others) did. Rolling out a new protocol would've taken years as well, so I don't think we've lost much time choosing this approach.
No. You and some other folks on HN expect that.
The general public does not know or care that HTTPS conflates multiple issues. Some random person who just wants to have a secure way to hit the login page of their blog does not know or care. There's room for a spectrum of things and ways to indicate where on that spectrum a particular site is, but HTTPS has been forced to be the one-size-fits-every-entity-in-the-universe solution and so has bundled in things that just aren't relevant to a lot of use cases and made it a binary "either you implement 100% of this 100% of the time or else" proposition when that makes no sense to do.
So hence, it's working.
Not quite. The general public is taught (often in school!) to trust “https://” links.
You can't trust that a self-signed certificate is from the site is claims. You don't even know if you're safe from your WiFi hotspot.
It doesn't matter whether you believe their actions are altruistic (protect everyone!) or sinister (protect the CAs!) ... by treating self-signed certificates as worse than nothing, they send a pretty clear signal to independents that it's the latter. Treating them both the same would be a great step toward building confidence to those who don't trust their actions currently.
Or about displaying a warning for websites using HSTS -- which Gmail does.
* Security without authentication (While slightly better than plain HTTP) is near useless in the real world. Without the authentication that CA trusted certificates provide, you have no guarantee that the host you are communicating with is the site and not a MitM attacker, all the certificate stops is passive eavesdropping.
* The SSH system of connecting to a host once and saving the certificate is unworkable on the larger web. You do not and can not know the certificate of any random site you visit, the CA system solves this problem.
* Browser vendors and CAs actively want websites to be using CA trusted certificates. If browsers accepted untrusted certificates a larger number of sites would use them, as opposed to CA trusted certificates.
* Unlike HTTP, a minuscule number of websites use unsigned certificates and as a result it is safe to penalise sites using them. The end game for browsers vendors is that every site uses a CA trusted certificate; this update to chrome further shows their intent to deprecate HTTP.
If they were treated like http there would be no dialogue.
Passive upgrade from HTTP to HTTPS would be a different thing.
In the case of Chrome visiting an untrusted CA, it already displays https:// in red with strikethrough, which seems like a perfectly adequate way to negate any expectation of security. So the scary warning which takes two clicks to pass seems like overkill.
If I was making a browser, I'd just show a "secure" symbol for valid, trusted certs, an "insecure" symbol for anything else, and no protocols in the URL bar.
It's easy to predict a future that's already happened!
Fun fact: if you have a .COM name, guess who becomes your de facto CA in an all DNSSEC+DANE world? You guessed it: Verisign!
Verizon may sign the .com TLD, but that's fine: there are lots of registration providers that offer free DNSSEC support for you (eg gkg.net). Once you have that, you can convey your certificate hash securely, and thus you no longer have to pay some racketeering jackass company $100-600 a year just to get "*.yourdomain.com" in the common name field.
The current reality with DNS is that it's the wild west. All this emphasis on security and yet a DNS provider is entirely unencrypted and hijackable by anyone to send you to an alternate domain. If you haven't visited the domain before, even HSTS/HPKP won't help you.
Why are we beating around the bush with this? DNSSEC is, on its face, a key escrow scheme. Why would we even consider adopting it?
You know that no party other than the sender has read or altered the resource in transit.
Do you really not see the difference there?
I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides.
Why people ignore such an obvious point is beyond me.
Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
Again: I link to my blog, with HTTPS
You have no idea who I am. "Bandrami" is not a meaningful string to you.
What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.
Why does this have to be forced to be such a jump-through-hoops-and-pay-strangers-money thing? Why shouldn't I just make my own cert, note its fingerprint, and call it a day? Why does my browser have to repeatedly go absolutely apeshit over that?
And more importantly, if this is really such a massive unbelievable vector that literally every web-connected computer on earth must behave this way, why does SSH still just say "want to trust this key? OK, I'll get out of your way now"?
Oh, and every browser I'm aware of allows you to import CA certificates, so why not just do that once and get a nice, green lock?
I don't know many non-technical users who use SSH regularly, but even for technical users, I doubt too many check the fingerprint, so the TOFU property of SSH is still a problem. That being said, SSH's TOFU is not all that different from the process of installing a CA certificate in your browser so ... just do that.
except that it's 10000 times easier and 10000 times easier to claim that the remote key and the key you just trusted is the same.
2) I'm pretty sure all the browsers work just like ssh -- where you can accept it once and then it doesn't bother you again.
Https is current form is snake oil.
Think about it, an encryption system that stops an end-point server from passing decrypted data to somewhere else is basically impossible. It would mean finding a DRM scheme that actually worked, and we know that's impossible because of the analog hole.
The only way to stop this would be for the end-point server to be unable to decrypt the data ever, but still manipulate it. That's called homonorphic encryption and it's still only theoretical.
1) Yes, browsers could accept SSL with a bad cert chain and just show the UI as if it was plain text. However, then they'd need to have multiple codepaths to support what should be a very rare occurrence, in a very security sensitive part of the code: you have to teach the address bar to display http:// when it's really https etc, because otherwise you're diluting the meaning of https, but URLs themselves still say https, etc. It's just complicated.
2) Your justification for why it's meaningful doesn't really work: if browsers used very long lived connections then it might be helpful but they don't, they re-negotiate and re-establish connections constantly. If an eavesdropper wants to MITM you and you aren't doing cert checking then they just need to wait a minute or two until you click another link on the page. It's not an especially interesting security upgrade. In your blog example you don't know the blog wasn't altered in transmission.
And it should receive the exact same treatment.
(And, yes, browsers are finally fixing this by warning on plaintext pages. About time.)
For untrusted certificates, the answer is clear: very severe. If https://www.facebook.com suddenly has an untrusted certificate, it is almost certainly a case of MITM. The typical end user is not in a position to make an informed decision about trusting it anyway "because it looks right", so the page should just be blocked. In current browsers, bypassing these warnings is very cumbersome. And frankly, making the warnings less conspicuous would be irresponsible.
Now, you may argue that plaintext is even worse than an untrusted certificate. But whether we like it or not, in today's internet a browser cannot just block all plaintext connections. Making plaintext warnings as conspicuous as untrusted certificate warnings is unrealistic.
That said, there are other steps browsers could take to keep pushing https. Browsers could warn when transmitting passwords unencrypted. And, I don't know if it goes too far, but perhaps browsers could even deprecate persistent cookies for unencrypted connections.
Very nice service.
According to the Netlify documentation[1], it looks like they support any/most tools, including Jekyll, Grunt, Middleman, Roots, Hugo, etc.
[0]: https://help.github.com/articles/using-jekyll-as-a-static-si...
I don't want a future where we need companies permissions to post on the internet. Especially not political stuff.
I'd argue Let's Encrypt's policy is as good as it can be while still following the policies required for root inclusion. Here's a relevant blog post[1].
[1]: https://letsencrypt.org/2015/10/29/phishing-and-malware.html
It's even worse in incognito mode now where the little padlock icon and "https" are both plain white, exactly the same color as the main URL. To a cursory glance, secure and non-secure both look very similar.
(The same site in Firefox: https://i.imgur.com/yrtypBZ.png )
It's possible that some sort of corporate MitM proxy is replacing the certificate in your case, or it's CT-related, as mentioned in a sibling comment.
Interesting that it shows up in your screenshot though; BoA on both Chrome 51 (on OS X) and Chrome 51 on Linux doesn't display the EV for BoA, or GitHub.
(I doubt the MitM one, since the Linux machine is my home one. The OS X one is my corp laptop, so corp MitM'ing is believable there.)
or is the screenshot incredibly outdated, since it says Chrome 8, and CT came later?
Yep, it should show up in the cert chain.
> Interesting that it shows up in your screenshot though; BoA on both Chrome 51 (on OS X) and Chrome 51 on Linux doesn't display the EV for BoA, or GitHub.
I'd guess for some reason Chrome doesn't think it has received a qualified SCT for the certificate and is refusing EV treatment. Not sure which SCT delivery methods Chrome supports, and why they might be failing here.
> or is the screenshot incredibly outdated, since it says Chrome 8, and CT came later?
It's definitely old, but I don't believe it's related. FWIW I'm getting the EV UI on OS X with Chrome 54 when I visit https://www.bankofamerica.com/.
Case in point - http://www.pinterest.onelogin.com
Tip: Select example.com and www.example.com and press 'Issue Multiple' to get 1 certificate that covers both!
Think of it, all of those brilliant http://c2.org wiki's and ASCII-doc sites are now marked "insecure".
Fundamentally -- some wonderful scientists and engineers created a paradise of free exchange. Commercial enterprise introduced the concept of 'money'. A bunch of thieves robbed them. And so we all have to put up walls with locks on them.
Finding so far: Yes, they will. No need to hurry, but I will go https eventually. Of the sites I checked quickly, these are running non-https by default:
http://www.tandf.co.uk (Taylor & Francis, bunch of engineering journals)
http://www.aps.org (American Physical Society, i.e. all the Phys. Rev. journals)
http://journals.cambridge.org (bunch of math and physics journals)
http://www.thomsonreuters.com (ManuscriptCentral, Scopus, the home of Impact Factor)
http://www.sciencemag.org (Science and other AIAA journals)
http://www.nature.com (Nature Publishing Group)
... and I couldn't be bothered to check more
Scatter sample: https://www.techdiary.co.uk/elsewhere [1]
[1] I run this, though only keep the NE section updated just now.
[0] Except maybe that they publish them. :-)
[1] Except the AMS, which, in my limited experience, seems to be populated by, and perhaps even more important, in the charge of, people who Get It.
This has very little to do with "corporations deciding the internet should be a predominantly private space", and everything to do with governments deciding that the internet is open season for information warfare and spying on citizens. The big push for HTTPS-everywhere hasn't been driven by "corporations affected by thieves", it's been driven in the wake of the Snowden revelations.
As long as Advanced Persistent Threats exist, you have no way of verifying you're even reading the real c2.org, or ASCII-doc site, or some censored replacement a privileged network opponent is impersonating it with.
HTTPS gives us some measure of security that we're talking with who we think we're talking with back.
Executing JavaScript from insecure http is a bad idea.[1] Especially for developers/IT admins who are targets of state sponsored hacking.[2]
>Please change your browser settings or upgrade your browser.
How about, no? There's a reason I block JS with noscript. It's not about page load speed, browser responsiveness, or ad blocking. (Although it helps in those areas remarkably) I block JS because executing untrusted JS code[3] is a good way to get hacked.
[1]http://www.metafilter.com/130629/Possible-FBI-infiltration-o... [2]http://www.infoworld.com/article/2609621/hacking/uk-spy-agen... [3]https://mazinahmed.net/uploads/Bypassing%20NoScript%20Securi...
Cookies are still harmful if no JS?
https://stormpath.com/blog/where-to-store-your-jwts-cookies-...
But that's coming from a site admin point of view. As a user, it would be great to have a browser plugin that allows me to reject cookies that aren't secure/httponly.
Never requires a lawyer or an accountant to fill in paperwork.
I'm going to give your team a try.
Everything else is (eg, https://www.chromium.org/Home/chromium-security/marking-http...) is directly linked in the post. There's nothing you can't easily verify.
I for one look forward to insecure HTTP becoming extinct.
https://www.netmarketshare.com/browser-market-share.aspx?qpr...
https://www.netmarketshare.com/browser-market-share.aspx?qpr...
EDIT: Thanks for the down votes! Unpopular thoughts like mine should be discouraged. Groupthink is best!
TLS operational costs are still higher, right?
Not necessarily. Once you enable and optimize your TLS stack you're also well on your way to deploying HTTP/2. Unlike HTTP/1.1, HTTP/2 requires only a single connection per origin, which means fewer sockets, memory buffers, TLS handshakes, and so on. As a result, it may well be the case that you will be able to handle more users with fewer resources.
See eg https://developer.yahoo.com/performance/rules.html#num_http=
Would you mind sharing the site in question and the modal (ie most common) specs of your users devices?
If your page is anything over a few KB in size you are really messing up then. Break CSS and JS into separate files so the browser can cache them and doesn't have to ask for them every single time the page is reloaded.
Http2 is different story.