Re:Sustaining Digital Certificate Security
by geofft on Wednesday October 28, 2015 @10:43PM
(#10468908)
The one thing you can do with such a system is to make it harder to compromise the code and get away with it. Any gossip system, public ledger, etc. (including "the blockchain", but you don't actually need something that power-hungry) can enforce that my copy of the JS is the same as everyone else's copy of the JS.
Right now it's easy to get in a network position between a single person and Gmail, without anyone else knowing, especially if you're a government, which is why a valid .google.com cert is such a valuable target. Getting in a position to compromise everyone's* copy of Gmail is much more involved, and if you pull it off, it's instantly visible to the entire world.
Re:Sustaining Digital Certificate Security
by david_ar on Thursday October 29, 2015 @01:19AM
(#10469422)
http://hyperboot.org/ solves some of these issues
Re:Sustaining Digital Certificate Security
by squidlogic on Wednesday October 28, 2015 @09:39PM
(#10468681)
Couldn't you have a browser plugin that would verify your js is being served up from the correct source?
Re:Sustaining Digital Certificate Security
by toomuchtodo on Thursday October 29, 2015 @01:26AM
(#10469442)
Subresource integrity (sort of) solves this.
It's the core problem really: how do you distribute your public key? How do you make sure Joe user gets the right public key? Today, we have the CA infrastructure, which admittedly isn't great, but… what would you do differently? (And the big problem is that it needs to work for average Joe.)