31–40 of 178 posts
I love that you can just buy a CA and devices will trust the new owner. That’s not messed up or anything.
How could you design a system that works otherwise? Computer security is always about "this key says", not "this legal entity says".
Earlier quoted context omitted.
Not any transparency. Certificate transparency. https://en.m.wikipedia.org/wiki/Certificate_Transparency
I think we are talking on different lines of thought. I am not concerned with certificate transparency... as the article you point out says it can take a long time [years] before it is found to be compromised. the fact of the matter is, if ssl decryption is possible on the fly, we need a different solution for encryption, this include the use of credit card chip. an encryption scheme cannot be designed to be broken a…
"One of the problems with digital certificate management is that fraudulent certificates take a long time to be spotted, reported and revoked by the browser vendors. Certificate Transparency would help by making it impossible for a certificate to be issued for a domain without the domain owner knowing."
I love that you can just buy a CA and devices will trust the new owner. That’s not messed up or anything.
How could you design a system that works otherwise? Computer security is always about "this key says", not "this legal entity says".
It should not be based on "root" certificates rather something more like blockchain for generating security keys and each roll /session generates a new key.
IANAEE but if building a currency is possible without it being possible to create fake money then it should be possible to protect websites in a similarly decentralised way.
Earlier quoted context omitted.
The certificates are OK. The issue is the way they are signed and distributed. Lots of issues with the current PK infrastructure is limited by the certificate transparency.
The main issue I see is ease of MITM for corporate environments. In a corporate environment a trusted root is installed, then an appliance can intercept all SSL certs and re-create the trust chain to introduce their own trusted root so they can read all SSL traffic and your browser says "SECURE". That is broken IMO.
I have no love for most the major CAs I've interacted with, but this feels wrong, though I can't quite pin point why. Perhaps just a general feeling that all the internet eggs are being put, one by one, in one single alphabet basket.
> this feels wrong, though I can't quite pin point why. It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this. (The announcement mentions that they might use this to operate as a…
Department of Defense: http://www.disa.mil/enterprise-services/identity-and-access-...
I think SSL certificates need to be replaced. Security can NOT be designed with the 'good guy' in mind. if it can be broken at all we need an alternative.
The certificates are OK. The issue is the way they are signed and distributed. Lots of issues with the current PK infrastructure is limited by the certificate transparency.
- We need clients to authenticate servers as well as the reverse.
- Browsers need to allow better user control over certificates. I know the reasons why this isn't provided, and I don't care. Add a "reset to defaults" if you're worried about people breaking their browsers, but a sensible way for users to control whom they trust is important. See next point.
- As of now, we have a pile of registries with near-zero public view into the operations of people with whom we're literally entrusting our bank accounts. Some of these are overtly in the control of nation-states, and many more are assumed to be at least covertly "assisting". Those of us with a problem with that (which should be everyone - even if you trust your friendly neighborhood intelligence agency, what about all the others?) need much better visibility into the operations of the CAs. I'd argue that they shouldn't even be for-profit operations, but that's not a huge point to me - the important points are knowing which ones are incompetent or compromised by their masters (which are the same thing in once sense, not not in others), and there are various paths to get there.
To the browser apologists: is a balkanized web worse than one that cannot be trusted? And are your actions actively harming people by making them believe it is trustworthy when it is not?
Earlier quoted context omitted.
The certificates are OK. The issue is the way they are signed and distributed. Lots of issues with the current PK infrastructure is limited by the certificate transparency.
The certificates have their own, independent problems (who thinks x509 is a good format?)
Earlier quoted context omitted.
How could you design a system that works otherwise? Computer security is always about "this key says", not "this legal entity says".
Peer review and regular key rolling should be built into the system. It should not be based on "root" certificates rather something more like blockchain for generating security keys and each roll /session generates a new key. IANAEE but if building a currency is possible without it being possible to create fake money then it should be possible to protect websites in a similarly decentralised way.
I have no love for most the major CAs I've interacted with, but this feels wrong, though I can't quite pin point why. Perhaps just a general feeling that all the internet eggs are being put, one by one, in one single alphabet basket.
> this feels wrong, though I can't quite pin point why. It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this. (The announcement mentions that they might use this to operate as a…
I wonder why browser won't automatically store the fingerprint for every HTTPS-certificate it encounters and throw up a fuzz to the user if a certificate changes without any good reason?