Scott_Helme_

Indeed the HTTP -> HTTPS redirect is only the first step in solving the problem.

A 301 redirect will offer some lasting protection as it can be cached but it's not really that great. The goal here is to take the first step to get on HTTPS and then longer term the sites can consider HSTS and eventually preloading.

This really highlights the problem that we need a proper technical solution for and not hacky traffic interception/redirects!

I also created http://httpforever.com/ for this purpose until such a time that the problem is solved properly.

It was screenshots taken for the purposes of demonstration and wasn't his publicly hosted site. Do you think that he'd take that kind of risk?

There's a difference between resolving something locally or setting up a demo for the purposes of capturing screenshots and having a website resolve on the public Internet and serve that content.

Phishing using EV, documented in 2011: https://news.netcraft.com/archives/2011/12/30/phishing-sites...

I can't find any copies of that in any cache showing it was ever actually online, simply mocked-up photos posted to social media.

This is kind of the point really isn't it. There was no forgery or abuse here, the certificate was issued in full accordance to the rules set out in the CA/Browser Forum Baseline Requirements and the EV SSL Guidelines.

If there were any abuse or forgery taking place here the certificate would have been revoked for those reasons and the CA would be held to account for mis-issuing a certificate. That's not what happened.

Given the name of the account that made the comment I'm curious about the affiliation of the author, perhaps they would share that in the interest of transparency?

More or less, yeah..

There is/was discussion in the standards body of using the SRI hash for exactly this purpose. It sounds really promising but iirc there was a privacy kink to work out.

Yeah, the best way to handle this is with a version in the path and then the host can knowingly/willingly upgrade the library version and SRI hash at the same time.

> As you live in the UK, and you noticed business you thought was local or US based turned out to be from the Philippines or Russia, would you care? It's essential the country be included.

If I "thought" it was local or if I "knew" it was local. The information is only useful if I knew it was local (prior knowledge) and EV UI tells me it's not (and I notice, and then act accordingly).

> You know more than that, you know the specific legal entity you are dealing with - the name is part of that

No, I really just know the name, because that's all that's in the EV UI unless I go digging...

> it just means we know which person you are.

And a DV certificate tells you which website I am, scotthelme.co.uk, which is what you typed into the address bar.

Something that I see a lot in the discussions around EV is "the EV indicator might make users feel" x, y or z.

Not to sound too harsh but I don't care about making the user 'feel' anything. I want to make them more secure.

I totally disagree with #2. What relevance is the country I reside or the country the company was founded matter? Half of the time companies have registered addresses all over the world for tax reasons, not to mention things like franchises, subsidiaries and other legal structures that complicate things further.

"I know who is handling my data", really? You know their registered name but nothing about them or who they are, where they are (in the country), are they big/small, reputable, been established 2 days or 2 years, have 5 staff or 500 staff, nothing. In all honesty, the browser presenting that to me in the address bar has absolutely no value. It's a simple text string, how can it?

I think completely the opposite. The sooner we can stop depending on the user to behave a certain way so that we can be secure, the better.

We told users for years to look for a padlock and https in the address bar before entering passwords or credit card details to make sure it was encrypted. Now we have HSTS so that websites can enforce https without having to have the user manually check things and risk missing something. HSTS does not place a burden on the user, we took responsibility from the user and fixed the issue without having to involve them. That's exactly how we improve security.

Clicking links in emails is another prime example. We can try to teach the user as much as we like for as long as we like but ultimately there's almost 8 billion people on Earth, so yeah, good luck on that front! Instead we can enforce policies like SPF/DKIM/DMARC to ensure the sender is genuine, check the reputation of domains linked in the body and filter them, scan attachments for malicious content, prevent execution of scripts, remove administrative privileges from the user and countless other technical measures we can deploy without even having to speak to the user once.

Every time we have to ask the user to do something or to not do something, the technology has failed.

I'm not opposed to your proposal but I would have some hesitation about an intersitial like that. The example works well with Amazon and Apple but what about:

- some-company.com - Other Company [United Kingdom] - some-company.com-fake.uk

Unless you already know you wanted Other Company [UK] (pre-existing knowledge) the EV indicator really doesn't help.

How is the user supposed to know what to verify in the EV indicator though? If the user is expected to know that the EV indicator should contain "Apple Inc.", why can't we just expect them to know the address should be apple.com instead, what's the difference?

I can't seem to get away from two key things that put me off and they are requiring the user to have some pre-existing knowledge of the name of the legal entity and then having to manually notice and verify that information on each page.

Let me list a couple of scenarios to see if I can better articulate my thoughts.

1) The user wants to buy something from ACME Corp so they search for them on Google and find acme-corp.com listed as their site. The user visits the site and sees in the EV indicator that this domain is indeed owned and verified as ACME Corp [US], the company they wanted to interact with. In this scenario the user is required to have pre-existing knowledge of who they wish to visit the site of and then manually verify that information.

2) A user is browsing the web and finds a product on a website that they want to buy. They check the address bar for https and also notice an EV indicator that says Bargain Central [UK]. Without existing knowledge of who the company is, what value does the EV indicator provide?

Maybe I'm missing something, and please do feel free to point out some other user scenarios, but #1 requires the user to have existing knowledge which is a pretty big burden to place on them. I can't really think up a scenario these days where someone would tell you a company name to buy something form or visit online but not their website address.

With #2 it seems to provide no value because the user has no reference as to who that company is. Given the information in the EV indicator the user would need to go and lookup information about the company somewhere else? We certainly can't assume that they're trustworthy just because they have an EV cert!

I honestly don't think the biggest problem with EV is browser UI. As I detailed in the linked article there are many scenarios when EV will never show because of AV/interception/proxies/etc and there's nothing that can be done about that. Even if all browsers had a consistent UI, my biggest concerns would still remain what they are now.

Agreed, that's exactly the purpose of EV. The problem is that the user has to know to look for EV, check it's present and check that it says "Apple Inc." which is a lot of things to expect of the user! There are also lots of scenarios that I outlined in my article where you would never see an EV indicator because of your browser, platform or TLS interception taking place. Not only do we burden the user but the indicator is also unreliable.

If apple.co was doing nasty things it'd also be blocked pretty quickly with things like Safe Browsing which is great.

This is my biggest real concern with EV, we depend 100% on the user for it to have any value.

I think we learnt that lesson with 'check for https in the address bar' and now we have HSTS instead.

Would the certificate really help you here though? If we look back at most of the big data breaches over the last few years then we regularly find out long after it's happened. It's generally a news story or a headline somewhere that xyz company was hacked.

I see what you're saying but I can't see where this would happen whilst the user has the browser window open showing EV information. If Twitter leaks your data you'd likely get an email notifying you or watch it on the news and then take action as a result of that.

In April next year we will have the CT requirement for all certificates so EV will lose an edge there.

For the pinning in a mobile app, would you still depend on the PKI or not just pin against your own private CA/certificates?

There is a huge presence of EV on financial sites where it is used considerably more than in any other sector. I never did come across a reasonable explanation for that though, I'd be interested to know why.

I do touch on that point in the article but the numbers show that larger sites are more likely to use EV and smaller sites are less likely to use it. The figures seem to go against the logical assumption. I grabbed the figures and published them because I thought as you do.

The only safe way to try and do that would be to make sure that the max-age of your policy was never more than the remaining validity of your longest valid certificate.

Having multiple backup keys doesn't really provide much benefit beyond having 2 well protected backups. Most of the same risks still exist like the minimum key size changing.

In many of my articles I discuss the various ways to deploy HPKP including leaf pins, intermediate pins and root pins, or even a combination of different types of pin. They all come with various challenges and considerations that a site needs to consider.

Hopefully this event will be 'market motivation' enough for them and any companies who will follow them. If this stuff is insecure it will be found and brought to light. The only question is will the good guys find it or the bad guys.

How about 'what a bunch of jerks to connect it to the internet and not secure it properly'?

Yeah, the 2 main issues with the VIN are as you say, the targeted vehicle in your presence, or enumerating all vehicles as they're sequential. Not great either way.

Rather unfortunate wording!

HPKP is HTTP Public Key Pinning, you aren't pinning certificates, you're pinning the public key. This means that you don't necessarily need to change any pins when you renew certificates as the certificate can use the same key pair. The only time you need to consume a backup pin when renewing the certificate is if you have a new public key signed. I think it's important to understand the difference before you try to deploy HPKP.

As for pinning the CA instead of your own public key, you can see my other comments in this thread with links about how GitHub pin their CA and a backup CA. I also have a link with information on the various levels in a chain you can pin at like the leaf, intermediate and root. Each has its own benefits and drawbacks.