Germany To Publish Standard on Modern Secure Browsers (zdnet.com) 61
Germany's cyber-security agency is working on a set of minimum rules that modern web browsers must comply with in order to be considered secure. From a report: The new guidelines are currently being drafted by the German Federal Office for Information Security (or the Bundesamt fur Sicherheit in der Informationstechnik -- BSI), and they'll be used to advise government agencies and companies from the private sector on what browsers are safe to use. A first version of this guideline was published in 2017, but a new standard is being put together to account for improved security measures added to modern browsers, such as HSTS, SRI, CSP 2.0, telemetry handling, and improved certificate handling mechanisms -- all mentioned in a new draft released for public debate last week. According to the BSI's new draft, to be considered "secure," a modern browser must follow the following requirements, among others: Must support TLS, must have a list of trusted certificates, must support extended validation (EV) certificates, must verify loaded certificates against a Certification Revocation List (CRL) or an Online Certificate Status Protocol (OCSP); the browser must use icons or color highlights to show when communications to a remote server is encrypted or in plaintext, connections to remote websites running on expired certificates must be allowed only after specific user approval; must support HTTP Strict Transport Security (HSTS) (RFC 6797). Further reading: Germany and the Netherlands To Build the First Ever Joint Military Internet.
I don’t regard any browser as secure (Score:3)
Re: (Score:3, Informative)
And web standards are now too complex for amateurs to compete.
Even if you skipped javascript, CSS alone is now so sprawling that creating your own hardware accelerated implementation would keep you busy for years.
Re: (Score:2)
I don't think that “Corporations pay them so their products can't be trusted” is good enough reasoning. You would have to demonstrate that corporations are interested in insecure browsers and that those corporations can leverage their power over browser makers.
Personally, I don't see how Google / Bing or any other search engine company would be interested in weakened TLS, overflow bugs, certificate forgery and so on. They would be much more interested in user tracking and such. Which leads to t
- The browser must not be made (Score:5, Interesting)
and controlled by a foreign Big Data company
- It must be open source
- The source must be reviewed by a local certification authority
- It must be recompiled and signed by said authority
That's what I'd add as a bare minimum for a standard for a "secure browser". Otherwise, it's yet another security theater.
Re: (Score:2)
The part about the "foreign big data company" is unnecessarily restrictive. The code has to be reviewed though.
"Big data companies" want to keep their product secure too, and they have money to to actually test their code and fix bugs, and they know their stuff about security, if only to protect themselves. Basically, they are in the best position to provide a secure browser. They can put in backdoors though, that's why an independent review is important, and so is open sourcing.
For that matter, do you know
Re:- The browser must not be SPONSORED either (Score:2)
It's worse than you know (Score:3, Interesting)
Just a few people from Google are churning out the spec. It's not democratic in the slightest.
Domenic Denicola is the Lennart Poettering of the web. Whatever he shit out gets rubber stamped and implemented in Chrome.
Firefox has almost no room for dissent.
The guy is an arrogant prick. Here's his blog, and you'll see what sort of mentality is generating the sprawl of modern web APIs.
https://blog.domenic.me/
Secure = disabled javascript. (Score:1)
We've seen that javascript is responsible for the vast majority of exploits. Without javascript, you don't get malware just by visiting a link!
To have a secure browser, it must not run javascript.
This also effects a more private browser, because the vast majority of browser fingerprinting techniques use javascript to discover the fingerprintable data.
Conflicting requirements (Score:3, Interesting)
Those two requirements are incompatible with each other. HSTS explicitly denies connections if the cert is expired.
Personally, I consider any standard that says I'm required to trust it absolutely as defective by design. If your standard is "we know what's best for you, shut up and sit down", you've disregarded the user's security completely.
Wonder how many more of these "requirements" are going to be in conflict with each other?
Not Germany, its just one of the german agencies.. (Score:2)
How about...? (Score:1)
The Operating System.
The Computer the Operating System is running on.
The Router the Computer is connected to.
The network routing and switching hardware the Browser, the Operating System, the Computer and the Router are connecting to.
Hmm!?
No JavaScript ... (Score:1)
No JavaScript and no capability whatsoever to run code (no javascript, no webasm, etc etc etc) is the only thing that will make a web browser secure. Pretty buttons and winken blinken lights do nothing other than look pretty and winken blinken and have no bearing whatsoever on "security". Security is that quality of imperviouslness against outside influences (that is, the opposite of safety, which mean that something will not influence things outside itself).
Should resist SSL Inspection (Score:4, Interesting)
We also need a way to tell the browser that the server operator does not consent to SSL inspection. For example:
1. Alice and Bob wish to communicate privately, by means of a server operated by Charlie.
2. Eve runs the corporate network, on which Bob's PC sits. She has installed an SSL proxy in the way, and has put a bogus cert on Bob's PC to allow this to function.
3. Alice, Bob and Charlie are all unaware of this, and none of them consent to snooping (and indeed, Charlie takes defensive measures using SSL).
[Bob may have given uninformed consent, or coerced consent when signing his work contract]
4. Charlie needs a way to tell Bob's browser that it should not trust a certificate that is signed by Eve (and if Eve disagrees, and owns the browser, Charlie needs a way to at least know that this is happening, in order to present a warning to Bob).
However, at the moment, there is no way to work around this. Browser vendors are uninterested in fixing this:
https://bugs.chromium.org/p/ch... [chromium.org]
https://groups.google.com/foru... [google.com]
Of course an MITM can do what it likes, so technically, it's game over at that point. But surely there is some way to make sure that the endpoint that runs the JS can return to the server the brower's view of what the server's SSL fingerprint is?
There is of course a question here of ethics and property rights, but it seems to me that any of the endpoints should have the right to ensure that the other endpoint is trustworthy.
Re: (Score:2)
In the scenario above, bob's endpoint belongs to eve and is only trustworthy for eve.
If bob doesn't want his communications being snooped by eve, he should not use a corporate system.
Corporate users NEED the ability to load their own SSL cert into the browser. If you allow private communication between the users and unknown third parties, then you provide a covert channel that can let malware in and let confidential data out.
If you want privacy, do not use an endpoint that belongs to someone else!
Re: (Score:1)
Arguably you still have some rights to privacy in the workplace. For example, employers shouldn't be able to put cameras in bathrooms. Your employer might permit you to do some personal stuff on their platforms, in which case they shouldn't snoop on your banking password. Part of the issue is that it is not just Bob's privacy which is violated, but Alice's and Charlie's. They don't work for Eve.
I'd say employers have a legitimate right to say how their facilities can be used, but that shouldn't extend to im
Re: (Score:2)
Re: (Score:2)
Employers can't put cameras in bathrooms, but they can and do put them in the general working environment.
Using company equipment is very different from using a bathroom. The equipment is provided so that you can do your job, not for your personal use.
Why should the company even provide internet access for staff at all? They are certainly under no obligation to do so.
Exfiltration of information by staff is one thing, communication and exfiltration by malware is quite another.
There is a visible flag, you can
Re: (Score:2)
Arguably, some companies might need this... but if so, at least:
- Alice needs to be able to explicit in her non-consent.
- Charlie needs to be able to find out that it is happening in order to have the choice to say "if you want to inspect, that's fine, but in which case, we simply won't provide service to you".
- Bob should know what's happening: i.e. Charlie should be able to take a technical measure to say to Bob via the infected browser: "your connection is not safe, you should not trust y
Re: (Score:2)
We also need a way to tell the browser that the server operator does not consent to SSL inspection.
This is already possible with HPKP, [wikipedia.org] but when it comes time to swap your certificate out, everything has to be perfect or your visitors will be unable to see your site. That makes cert-swapping somewhat of a minefield, with some people using phrases like "footgun," "HPKP suicide," and "nuke your site off the internet for months/years."
In theory, it's even possible to get your cert keys preloaded into the browser for TOFU, but last I checked only 9 sites on the whole internet do that.
Only one real choice. (Score:2)
It's also the only browser that prevents viral content from crossing over to infect humans. Youtube, Facebook and Instagram are rendered entirely harmless by the lack of render support.