×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Mozilla To Support Public Key Pinning In Firefox 32

Soulskill posted about 3 months ago | from the pin-the-key-on-the-fox dept.

Firefox 90

Trailrunner7 writes: Mozilla is planning to add support for public-key pinning in its Firefox browser in an upcoming version. In version 32, which would be the next stable version of the browser, Firefox will have key pins for a long list of sites, including many of Mozilla's own sites, all of the sites pinned in Google Chrome and several Twitter sites. Public-key pinning has emerged as an important defense against a variety of attacks, especially man-in-the-middle attacks and the issuance of fraudulent certificates. The function essentially ties a public key, or set of keys, issued by known-good certificate authorities to a given domain. So if a user's browser encounters a site that's presenting a certificate that isn't included in the set of pinned public keys for that domain, it will then reject the connection. The idea is to prevent attackers from using fake certificates in order to intercept secure traffic between a user and the target site.

Sorry! There are no comments related to the filter you selected.

Not far enough (0)

Anonymous Coward | about 3 months ago | (#47787029)

They should enable the user to visit an HTTPS site (e.g.: his bank) and tell Firefox to remember the entire certificate chain. If a subsequent visit uses a different chain, show an warning and do not continue without manual intervention.

Re:Not far enough (0)

Anonymous Coward | about 3 months ago | (#47787111)

And if I get such a warning, what would I do? Call the bank's tech support? That sounds painful.

Re: Not far enough (3, Interesting)

Anonymous Coward | about 3 months ago | (#47787159)

If Mozilla would just implement DANE that would solve the problem.

Re: Not far enough (-1)

Anonymous Coward | about 3 months ago | (#47788905)

Then everyone outside Denmark is screwed. No way.

Re: Not far enough (2)

marka63 (1237718) | about 3 months ago | (#47789461)

Not DANE the people, DANE (DNS based Authentication of Named Entities) http://tools.ietf.org/html/rfc... [ietf.org] Mozilla are in a position to both publish TLSA record and authenticate the CERT.

Re: Not far enough (-1)

Anonymous Coward | about 3 months ago | (#47789483)

No thanks. I'd much rather be screwed by the other kind of Dane then. Have you seen some of them? It's like Super Model Planet over there!

Wreak havoc on corporate networks, SSL observatory (1)

MobyDisk (75490) | about 3 months ago | (#47787041)

This is a good idea, but I bet it will not work well on corporate networks that do MITM attacks: every cert will be wrong. This same thing happens if you use the SSL Observatory add-on. This clearly shows how the public key infrastructure implementation is completely flawed.

Re:Wreak havoc on corporate networks, SSL observat (4, Insightful)

MobyDisk (75490) | about 3 months ago | (#47787055)

Sorry! I'm totally wrong! The corporate MITM will work just fine once it is updated:

The UA will not be able to detect and thwart a MITM attacking the
      UA's first connection to the host. (However, the requirement that
      the MITM provide an X.509 certificate chain that can pass the UA's
      validation requirements, without error, mitigates this risk
      somewhat.) Worse, such a MITM can inject its own PKP header into the
      HTTP stream, and pin the UA to its own keys. To avoid post facto
      detection, the attacker would have to be in a position to intercept
      all future requests to the host from that UA.

Re:Wreak havoc on corporate networks, SSL observat (0)

Anonymous Coward | about 3 months ago | (#47787235)

The Firefox, just as Chrome does, supports a list of pre-pinned sites. For these sites there is MITM protection because they don't first access the site to get the PKP header. Both Firefox and Chrome have a mechanism for you to submit your site for inclusion in their list.

That being said this will still not break corporate MITM because the default setting for both browsers is to ignore pinning if the certificate is signed by a CA added to the local CA store versus the public CA store which ships with the browser or OS.

Re:Wreak havoc on corporate networks, SSL observat (1)

Ash-Fox (726320) | about 3 months ago | (#47788691)

I have yet to encounter corporations applying policies or default configurations to firefox. Often there are just instructions left for configuring the browser in my experience (as opposed to the corporation Chrome, IE installs).

Re:Wreak havoc on corporate networks, SSL observat (3, Informative)

Charliemopps (1157495) | about 3 months ago | (#47787599)

Sorry! I'm totally wrong! The corporate MITM will work just fine once it is updated:

Props for correcting yourself. Integrity's sexy.

Re:Wreak havoc on corporate networks, SSL observat (0)

Anonymous Coward | about 3 months ago | (#47789155)

So therefore it is guaranteed to screw up on any device that uses multiple networks. Such as corporate laptops or BYOD.

Lets face it, the only browser that seems to give a toss about the corporate environment is IE, as much as that pains me.
Google Chrome recently had a serious bug that hammered corporate authenticating proxies with huge numbers of requests for over a month before they released a fix. Users couldn't revert to an earlier version, and the only workarounds required manually getting users to follow certain steps every 7 days.

I think many corporate environments banned chrome after that, looks like firefox will be next.

Re:Wreak havoc on corporate networks, SSL observat (1)

robmv (855035) | about 3 months ago | (#47787221)

The default is:

  1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)

So CAs inserted by the corporate networks will be allowed, only verified for CAs shipped by Mozilla

Re:Wreak havoc on corporate networks, SSL observat (1)

mrops (927562) | about 3 months ago | (#47787257)

And that is the intention, I don't want MITM attack by my company or anyone else.

Re:Wreak havoc on corporate networks, SSL observat (2)

BitZtream (692029) | about 3 months ago | (#47787435)

Then perhaps you should browse personal sites on your own dime, not the company network.

Re:Wreak havoc on corporate networks, SSL observat (1)

0123456 (636235) | about 3 months ago | (#47787781)

Then perhaps you should browse personal sites on your own dime, not the company network.

Then what's the problem? Mozilla will no longer let employees do that.

Re:Wreak havoc on corporate networks, SSL observat (0)

Anonymous Coward | about 3 months ago | (#47787505)

You will want to avoid working for companies that will soon have mandated data leakage prevention policies, such as those governed by FFIEC or HIPAA. Auditors and federal examiners will interpret the mandate to mean all outbound Internet traffic must be inspected.

Re: Wreak havoc on corporate networks, SSL observa (0)

Anonymous Coward | about 3 months ago | (#47787563)

That is why people who care about privacy should avoid such employers.

Re: Wreak havoc on corporate networks, SSL observa (0)

Anonymous Coward | about 3 months ago | (#47787687)

Or be private in private.

Re: Wreak havoc on corporate networks, SSL observa (1)

kwbauer (1677400) | about 3 months ago | (#47788023)

So people who care about privacy should avoid working for companies that are being forced by regulations to care more about privacy? That somehow does not seem to be the best recipe for success in helping companies who should be caring about privacy.

Re:Wreak havoc on corporate networks, SSL observat (1)

MobyDisk (75490) | about 3 months ago | (#47806913)

This AC makes a key point: It is the auditors who decide the real policy. Sometimes that is good since I don't want politicians deciding those details. But the bad part is that the auditors, when faced with ambiguous language, will overreact and require nearly impossible things like keeping all web pages served for the next 10 years.

Re:Wreak havoc on corporate networks, SSL observat (1)

Anonymous Coward | about 3 months ago | (#47788717)

Without commenting on whether, and in what circumstances, it's wise for companies to operate MITM firewalls:

It seems to me that this change should, in fact, make such firewalls more secure, because it'll encourage web server admins to start using PKP, which will allow the firewall to better verify the remote server identity. (Whether the creators of the firewall software will actually implement this feature is of course another question, but anyway...)

In fact, PKP itself will be more effective if it's implemented at the firewall, because in that case only *one* user has to visit a given site for *everyone* to be protected against future MITM attacks.

Re:Wreak havoc on corporate networks, SSL observat (0)

Anonymous Coward | about 3 months ago | (#47789035)

I, for one, hope it puts companies like Blue Coat Systems Inc and their re-encrypting internet appliances out of business.

Re:Wreak havoc on corporate networks, SSL observat (1)

jonwil (467024) | about 3 months ago | (#47789223)

If you are the IT director of a big corporation, you have no option but to MITM SSL traffic. The alternative is providing a perfect way for malicious insiders to steal corporate secrets (like a whole pile of credit card numbers or the blueprints/source code for the companies latest products). And providing a vector for malware or attacks to bypass all the edge-level intrusion detection systems.

And providing a way for the people on the inside to access things that they shouldn't (whether its pornography, pirated content, or anything else). That last one is even more important in, say, a school or educational environment or library than in a corporate network.

Re:Wreak havoc on corporate networks, SSL observat (1)

Lennie (16154) | about 3 months ago | (#47790229)

You can also configure every browser to use a proxy-server and then block all the other webtraffic at the firewall.

Re:Wreak havoc on corporate networks, SSL observat (1)

jonwil (467024) | about 3 months ago | (#47792753)

Except that the proxy server will have to MITM SSL for it to work.

Re:Wreak havoc on corporate networks, SSL observat (1)

Lennie (16154) | about 3 months ago | (#47790223)

You mean what corporate networks are doing is wrong. That is the biggest flaw.

They should move to a model of a proxy configured in the browser. The browser then can trust the proxy.

Re:Wreak havoc on corporate networks, SSL observat (1)

MobyDisk (75490) | about 3 months ago | (#47806967)

I am unclear on all this, but "the browser then can trust the proxy" seems to mean that same thing as the MITM. The proxy issues a cert, and the browser has to trust that cert. It is a form of MITM attack: except you know and (supposedly) trust the MITM.

Still uses CAs (0)

Anonymous Coward | about 3 months ago | (#47787047)

"Known good," eh?

Re:Still uses CAs (1)

Anonymous Coward | about 3 months ago | (#47787143)

The ones "no one" *wink* *wink* knows is compromised by state agents.

Good idea (3, Insightful)

Anonymous Coward | about 3 months ago | (#47787061)

Lets patch an inherently broken system with another inherently broken system that does not scale and will cause a whole new range of unwanted side-effects and problems.

Please... (5, Insightful)

Anonymous Coward | about 3 months ago | (#47787081)

What ever public-key pinning is. How about a stable 64-bit version for Windows, and actually fix the bugs in their software (yeah, Thunderbird too) that have been actively open for *years* instead of wasting time a mobile OS that nobody uses, and features that aren't really relevant. Hell, just working on the things that are broken might fix the issues they're pushing through as new features.

Re:Please... (0)

Anonymous Coward | about 3 months ago | (#47787187)

Wish I could mod you up for that.. One of the reasons I dumped Mozilla's products a long time ago.

Re:Please... (0, Troll)

ysth (1368415) | about 3 months ago | (#47787205)

You lost me at "Windows".

Re:Please... (0, Troll)

Anonymous Coward | about 3 months ago | (#47787225)

He lost you down in your parents' basement.

Re:Please... (2)

hairyfeet (841228) | about 3 months ago | (#47789251)

Try Pale Moon [palemoon.org] friend. Its based on FF so you can keep your plugins, has a native 64bit build, oh and the best part NO STUPID NEW UI, in fact the devs have stated they will NOT be going to the new UI PERIOD. its fast, stable, works so well in fact I've started using it as my default browser even over my beloved Comodo Dragon because its even snappier, just a really great browser all around.

Re:Please... (4, Interesting)

tlhIngan (30335) | about 3 months ago | (#47789863)

How about a stable 64-bit version for Windows,

THere were stable builds for Windows. The problem was people needed plugins which weren't available (because a 64-bit browser can't run 32-bit plugins without a thunk layer). Chrome did it because Chrome ships with the plugins recompiled for 64-bit (because Google has the source code to Flash and all that).

It's the same reason why Microsoft actively discourages use of the 64-bit version of Office.

Though, other than being "64-bit", is there a real reason for having a 64-bit browser?

Okay... (0)

Anonymous Coward | about 3 months ago | (#47787157)

Okay. But where's the warranty for guaranteeing these "pinned" public keys?

Re:Okay... (1)

kwbauer (1677400) | about 3 months ago | (#47788033)

How about they refund the purchase prices of the browser?

Re:Okay... (0)

Anonymous Coward | about 3 months ago | (#47788925)

I should get DOUBLE my money back to compensate me for my inconvenience.

Re: Okay... (0)

Anonymous Coward | about 3 months ago | (#47790875)

Sold!

When will it support killing CPU-hogging tabs? (5, Insightful)

Kethinov (636034) | about 3 months ago | (#47787167)

When will Firefox support killing CPU-hogging tabs individually?

That's the only killer feature from Chrome I'm waiting for to switch back to Firefox.

In Chrome, if I've got 50 tabs open (not uncommon) and one of them starts spiking my CPU, I can pull open Activity Monitor (on OS X) and kill the "Google Chrome Helper" that's eating all the CPU.

That kills the one tab that was the problem, not the whole browser. And lets me reload it when I actually care about that tab again.

I haven't found a similar way to imitate this workflow in Firefox.

The whole noscript / flashblock / adblock / etc approach hasn't worked. Tried it with Firefox, still had constant CPU issues after whitelisting sites I need JS or Flash turned on for, still had no way to kill runaway processes individually.

Re:When will it support killing CPU-hogging tabs? (5, Insightful)

Anonymous Coward | about 3 months ago | (#47787209)

They are too busy ruining the user interface and removing customization features to actually copy any of the good features of Chrome.

Re:When will it support killing CPU-hogging tabs? (0, Troll)

Anonymous Coward | about 3 months ago | (#47787229)

It's because *barf* UX designers *barf* are ruining the web and most software.

Re:When will it support killing CPU-hogging tabs? (1)

Anonymous Coward | about 3 months ago | (#47789079)

^^^ This. "Skype could not connect" is an example of the least helpful error message ever to come out of a Ux designer's arse. The lack of any kind of disclosure, or any communications log in the file system, means it is impossible for a user to diagnose and correct the actual issue. Who would guess that "Skype could not connect" might actually mean "Your version of Skype is out of date and you've been locked out. Please visit www.skype.com in a web browser to download and install the latest version of Skype."

Re: When will it support killing CPU-hogging tabs? (1)

Anonymous Coward | about 3 months ago | (#47790887)

That would reveal too much about what they're trying to connect to and why.

You should just sit back and not be concerned. Now citizen, go back in your cube.

Re:When will it support killing CPU-hogging tabs? (1)

John Bokma (834313) | about 3 months ago | (#47787467)

Yup, including simple stuff like changing the address bar default search URL. Now one has to install an add-on to do so, instead of just going to about:config. GnomeZilla, the monster that feeds on usability.

Re:When will it support killing CPU-hogging tabs? (0)

Anonymous Coward | about 3 months ago | (#47788183)

Actually, they are copying the good features, it just takes time. Even "ruining the interface" took 5+ years. But nobody cares, so it hardly matters. It's far easier to just say they're ruining Firefox instead of paying attention or (gasp!) actually helping, so I guess I might as well just shut up and join in the constant anti-Mozilla circlejerking.

Re:When will it support killing CPU-hogging tabs? (0)

Anonymous Coward | about 3 months ago | (#47789031)

Sup Asa. Trolling as AC again?

Re:When will it support killing CPU-hogging tabs? (3, Informative)

Etzos (3726819) | about 3 months ago | (#47787401)

Probably sometime after electrolysis[1] (e10s) lands. That's probably going to take a while because there's a lot to do between now and when it will be deemed release ready (add-on compatibility, switching some internal components over to e10s friendly versions, memory checks, and various other odds and ends).

If it's flash or other plugins that were causing the CPU usage then recent versions of Firefox already have that covered. Plugins can be set to click to activate (so it will only run on sites you enable it for) and if one does run out of control then killing the "plugin-container" child process will kill all of the plugins (which can then be reloaded by reloading the tab). As for Javascript running out of control for a particular tab, there's no current solution.

[1] https://wiki.mozilla.org/Elect... [mozilla.org]

Re:When will it support killing CPU-hogging tabs? (1)

Lennie (16154) | about 3 months ago | (#47790239)

The electrolysis project is scheduled to go into the stable release at the end of this year. If it will be enabled by default this year I don't know. My gut feeling is they'll do so early next year.

Re:When will it support killing CPU-hogging tabs? (0)

Anonymous Coward | about 3 months ago | (#47788663)

In Chrome, if I've got 50 tabs open (not uncommon) [...]

You're the kind of guy who has thousands of old emails sitting in his inbox aren't you? Or maybe desktops full of icons?

Re:When will it support killing CPU-hogging tabs? (1)

Kethinov (636034) | about 3 months ago | (#47789061)

Guilty as charged on all counts.

Mozilla is on the decline (0)

Anonymous Coward | about 3 months ago | (#47787183)

and now they are just nother browser. Mozilla is trying too hard to be like Google. This is killing their chances at being a successful stand-alone company.

And, even better yet, Firefox 64 (1)

Mister Liberty (769145) | about 3 months ago | (#47787241)

... will have air gapping and sneakernet.
My salute to FF -- you are not the problem, but you are not the solution either.

Re:And, even better yet, Firefox 64 (0)

Anonymous Coward | about 3 months ago | (#47787279)

Isn't that coming out this coming Tuesday?

Re:And, even better yet, Firefox 64 (1)

Ash-Fox (726320) | about 3 months ago | (#47788669)

Please come up with new content for jokes already.

Re:And, even better yet, Firefox 64 (0)

Anonymous Coward | about 3 months ago | (#47788947)

New jokes won't be available until Firefox 75, which comes out Wednesday.

I dont get it (0)

Anonymous Coward | about 3 months ago | (#47787325)

The whole point of certs is to prove that something came from you. If anyone can sign your page and browsers will accept it then what was the whole point of certs? Why don't certs work like this allready?

Maybe I should go RTFA now.

Re:I dont get it (1)

0123456 (636235) | about 3 months ago | (#47787819)

If you ask google.com for a certificate and it sends you one that's not for google.com, your browser will already warn you.

But...if the government of Mitmistan signs a certificate that claims to be google.com, your browser will accept that, even though it's actually being used by the government to hijack your browser session.

The whole CA thing worked OK when there were only a few CAs, but it's a disaster today when there are about a bazillion of them and any of them can sign a certificate pretending to be any site in the world.

Re: I dont get it (0)

Anonymous Coward | about 3 months ago | (#47790901)

As presiding ruler of Mitmistan, I need to know what you're thinking.

Why a hardcoded list? (5, Insightful)

diamondmagic (877411) | about 3 months ago | (#47787559)

Why does the list have to be hardcoded? Why not pull the records from DNSSEC... there's a whole specification for this, RFC6698 [ietf.org]

Re:Why a hardcoded list? (1)

Anonymous Coward | about 3 months ago | (#47787611)

Because that would make sense?

Re:Why a hardcoded list? (2)

Nimey (114278) | about 3 months ago | (#47787649)

Because hardly anyone uses DNSSEC, ISPs included.

Re:Why a hardcoded list? (-1)

Anonymous Coward | about 3 months ago | (#47787711)

And hardly anyone wants to have sex with you, hookers included.

Re:Why a hardcoded list? (2)

Nimey (114278) | about 3 months ago | (#47788545)

Look, I said I was sorry, I didn't know she was your mom!

Re:Why a hardcoded list? (0)

Anonymous Coward | about 3 months ago | (#47789063)

No need to apologize. She had a great laugh at your micropeen. I hear her work jacking you off with tweezers was incredible.

Re:Why a hardcoded list? (0)

Anonymous Coward | about 3 months ago | (#47788845)

It ought to be possible to work around that at the HTTP level, I would think. The web server itself could cache the full set of DNSSEC signatures, from its own domain all the way up to the root, and provide them at some standard URL. The client would attempt to download and verify the chain whenever it sees a public key it hasn't seen before. (It'd be a little tricky since you have to be sure not to send any cookies or authentication data with that initial request - but the problems aren't insurmountable.)

Of course, this would not be quite as secure as requiring the client to get the information via its own DNS servers, but it would mean that a MITM would have to break two separate chains of signatures.

OpenDNS does... apk (0)

Anonymous Coward | about 3 months ago | (#47795069)

See subject: It uses it between it & its upstream updaters + OpenDNS = patched vs. Kaminsky flaw (security issue in redirect poisoning).

As you pointed out: 99.999% of ISP DNS', don't, & aren't patched vs. Kaminsky bug either

(Even though a patch has been out for nearly a decade (due to MX records setup problems iirc)).

I use it because of that, in combination with custom hosts files which I have COMPLETE LOCAL CONTROL OVER!

(For extra speed, security, reliability, & even anonymity (vs. dns request logs OR to get around DNSBL's I may not like), & they do so more efficiently and DO MORE than any 1 browser addon does, minus their messagepassing & cpu + ram hogging overheads in slower usermode, since hosts are part of the kernelmode IP stack + the 1st resolver queried by the OS... heck with redundant SLOWER browser addons).

* OpenDNS + custom hosts files go together like 'bread & butter' for faster, better & more reliable, + safer websurfing, all the way around (& hosts fix dns security issues too - bonus) + DNS admins must love me (lol) - I lighten up their request loads too.

APK

P.S.=> APK Hosts File Engine 9.0++ 32/64-bit: http://start64.com/index.php?o... [start64.com]

... apk

Re:Why a hardcoded list? (1)

Anonymous Coward | about 3 months ago | (#47787971)

If you are in a MITM position already, you may be able to MITM the response from DNSSEC to suit your needs. At the very least, you must hardcode the cert to DNSSEC to be certain you know you are talking to them. This also creates an additionally dependency and latency (what if DNSSEC doesn't respond? how long is waited?).

Re:Why a hardcoded list? (2)

KiloByte (825081) | about 3 months ago | (#47788869)

Uhm no, you can't MITM DNSSEC, you can't do anything except a denial of service unless you control one of three entities:

  • ICANN
  • that particular TLD
  • the registrar your victim uses

That is, unless someone is stupid enough to trust some external DNS server, but no reasonable DNSSEC client would use a dumb stub resolver this way.

Re:Why a hardcoded list? (0)

Anonymous Coward | about 3 months ago | (#47789209)

"Uhm no, you can't MITM DNSSEC, you can't do anything except a denial of service unless you control one of three entities:"

So kinda like OCSP or CRLs, and how well do browsers support them in sacrificing performance over security?

Re:Why a hardcoded list? (0)

Anonymous Coward | about 3 months ago | (#47789397)

CRLs are fucked from the beginning because they're usually served over HTTP so it's trivial to MITM them to return a fake empty list.

Re:Why a hardcoded list? (1)

Lennie (16154) | about 3 months ago | (#47790245)

Empty list also need to be signed. So no.

Re:Why a hardcoded list? (1)

LordLimecat (1103839) | about 3 months ago | (#47791419)

It wouldnt matter if they were served over HTTPS. All you have to do is block CRLs or OCSP responses and the browser will say "Lol, whatever" and continue with the connection.

Plus theres the whole "HTTPS is already broken if you have untrustworthy root CAs in your chain" (which you do).

Re:Why a hardcoded list? (2)

AmiMoJo (196126) | about 3 months ago | (#47790661)

Many of the registrars ARE controlled by the enemy which these days is usually the state. In some places the government just forces them to issue dodgy certificates, in others GCHQ or the NSA just hacks them.

Re:Why a hardcoded list? (2)

Rich0 (548339) | about 3 months ago | (#47792925)

Many of the registrars ARE controlled by the enemy which these days is usually the state. In some places the government just forces them to issue dodgy certificates, in others GCHQ or the NSA just hacks them.

Keep in mind that you would have to have control of the registrar that issued the domain. With SSL today anybody on the trusted CA list can impersonate any website anywhere. With DNSSEC Verisign certainly could impersonate .com websites, and Iran certainly could impersonate .ir websites, but neither party could impersonate the other's websites. That is a BIG reduction in the vulnerability space, even if it isn't perfect.

If the NSA really does has everybody under their thumbs, then face it, you aren't going to be able to evade them using anything likely to ever become mainstream. We can't judge every security improvement solely on whether it solves "the NSA is out to get me."

Re:Why a hardcoded list? (1)

AmiMoJo (196126) | about 3 months ago | (#47794429)

We can't judge every security improvement solely on whether it solves "the NSA is out to get me."

The NSA and GCHQ are out to break the internet, so I'm afraid that is the benchmark which we have to use. They spy on everyone, and spoof sites like Slashdot to deliver malware. They prefer to hack other people's servers, i.e. your computer, and use them to attack their more specific targets.

While Iran might find it hard to impersonate .com sites, I bet that the NSA/GCHQ can impersonate .ir sites. That is a major concern for everyone, not just Iranians, because they are know to hack infrastructure providers in Europe and pretty much any other part of the world for this very purpose.

Re:Why a hardcoded list? (1)

Rich0 (548339) | about 3 months ago | (#47794621)

We can't judge every security improvement solely on whether it solves "the NSA is out to get me."

The NSA and GCHQ are out to break the internet, so I'm afraid that is the benchmark which we have to use. They spy on everyone, and spoof sites like Slashdot to deliver malware. They prefer to hack other people's servers, i.e. your computer, and use them to attack their more specific targets.

So, what solution do you actually advocate then? Right now the NSA/GCHQ can still break the internet, and so can about a million other people. Oh, and everybody gets to pay $100/yr or so for every webserver they run, and virtual hosting is a pain.

DNSSEC is a lot better than what we have now. Moving to it doesn't prevent us from moving to something even better assuming that somebody figures out what it is.

While Iran might find it hard to impersonate .com sites, I bet that the NSA/GCHQ can impersonate .ir sites. That is a major concern for everyone, not just Iranians, because they are know to hack infrastructure providers in Europe and pretty much any other part of the world for this very purpose.

The only solution to that is to have ICANN be under the control of somebody that everybody can trust. Either that, or give up on having a single root. There isn't any reason that you couldn't hard-code into the browsers the keys of the TLDs, other than it making those keys harder to change.

Of course, that isn't going to help you all that much, because if the NSA needs to impersonate a European domain they'll just nicely ask the government hosting it for the keys and they'll cooperate, since while they all complain about the NSA in public the fact is that they love having access to all that data.

Re:Why a hardcoded list? (1)

LordLimecat (1103839) | about 3 months ago | (#47791441)

Im a bit rusty on DNSSEC so I went to look it up to see if that were true.

DNSSEC works by digitally signing records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust,

So, no, you can MITM it in the exact same way you can MITM SSL. It uses a chain of trust with a trusted authority installed on each client, just like SSL, and just like SSL, whatever country hosts the root key for a TLD is subject to subpoena and global MITM.

ICANN

Or, whoever hacks ICANN, or whoever demands their keys....

that particular TLD

Good thing there are so few of them, owned by so few countries... oh wait. You think your ".cn" or ".co.hk" results are gonna be unadulterated?

Re:Why a hardcoded list? (2)

KiloByte (825081) | about 3 months ago | (#47793801)

The .cn TLD is can be MITMed by the Chinese government, yes. That's why you need to host your chinese-dissident page in a TLD of any country that hates China (ie, almost any of them). Same for a site that reveals wrongdoings of the NSA. Any point other than ICANN can be avoided by simply chosing a different TLD, and ICANN itself can be secured by pinning TLD keys.

This goes in sharp contrast with the CA cartel model, where you need to trust the sum (rather than alternative) of 400+ entities, some of which are known to be actively engaged in MITM, like CNNIC or Etisalat.

Mozilla (0)

Anonymous Coward | about 3 months ago | (#47787973)

Can we hope for a blue snowfox who's pinning for the Fjords?

Re: Mozilla (0)

Anonymous Coward | about 3 months ago | (#47791395)

What does the fox say?

FIREFOX IS DEAD... (1)

Anonymous Coward | about 3 months ago | (#47788025)

...Pale Moon for ever!!!!

http://www.palemoon.org/ [palemoon.org]

Great idea (0)

Anonymous Coward | about 3 months ago | (#47789153)

But I don't see mention in any of the links about how they maintain integrity of the public key list itself. Mozilla itself is not immune to compromise or influence but even if we assume that the source list will always be secure how about when it's in-transit to the browser clients? Even over SSL there could still be MITM attacks that modify the contents of the list to include the MITM attacker's public keys. Presumably the in-transit list will be public-key signed, as with manifest files, so as to be verified by the browser before it updates or replaces its existing list. How will it then be secured in the browser's file system? In memory?

Most SSL certificates have a cost and expire (1)

mgf64 (1467083) | about 3 months ago | (#47789217)

Usually certificates have an arbitrary high cost, expire yearly, need to be reissued because you need to add a subdomain (and "wildcard" certificates are usually very expensive). I can see trouble for all but a few domains, who will register certificates for decades, maybe because they have their own c.a.

Re:Most SSL certificates have a cost and expire (1)

Lennie (16154) | about 3 months ago | (#47790261)

What probably happens is that a big site says: we use CA 1 and CA 2.

Then uses CA 1. After that when CA 1 is somehow a problem they switch using certificates from CA 2 they have already prepared and ready for use.

Certificates are dead, long live the keys (1)

shpokas (3537953) | about 3 months ago | (#47790271)

So they have given up on certificates alone, don't they?

Stable (0)

Anonymous Coward | about 3 months ago | (#47791285)

But how many of my addons won't work? The version number wars between the browsers is silly.

I hope you can turn this off (1)

cant_get_a_good_nick (172131) | about 3 months ago | (#47791463)

We've had some source code theft recently at my job, so we have an SSL MITM proxy that generates a work SSL cert for everything. At first I hated it, but it is a work comp, and they provide a dirty LAN, so just bring your device if you want to browse your mail.

But, this would break Google searches for me. I wouldn't be able to look at any Google site, no Google searches, no wikipedia, no stackoverflow on my work comp with this. Make this a hard to find, no normal person would be able to find it, only geeks can flip the switch, config to turn this off please.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?