6 ms·

As a bit of a layman, is there even any legitimate reason at all (other than a user installing it in their own machine for reverse engineering purposes) for any

As a bit of a layman, is there even any legitimate reason at all (other than a user installing it in their own machine for reverse engineering purposes) for anyone to install a root certificate anymore? I could understand it if it was a small company doing so at the time when certificates were expensive, but Sennheiser has plenty of money and certificates can be obtained for free nowadays.

tyingq 8y ago
Corporate MITM proxies, like Forcepoint/Websense. For loose definitions of "legitimate."
zorked 8y ago
It's perfectly normal to install new root certificates - for example, so that a company can sign internal websites (or for MITM proxies). It's incredibly shady to have random software install into your trust store.
- rblatz 8y ago
  As someone that has been burned by self signed internal only sites. Take the extra 15 minutes and get a proper cert, and domain name for your internal sites. It can save a massive amount of pain later.
  - zAy0LfpBZLC8mAC 8y ago
    burned how exactly?
    - hannasanarion 8y ago
      It can be a real pain in the butt to go up and down the whole stack and reconfigure every library and application that might detect a insecure connection and bail. Need several independent webapps to communicate? Hoo boy.
    - rblatz 8y ago
      In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to clean the mess completely up.
      - zAy0LfpBZLC8mAC 8y ago
        Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good idea as well. Relying on an external CA for internal services just creates risks of both availability and security. If you need an external CA to set up or continue operating internal services, that is an availability risk, and if you trust the whole standard set of root CAs for all of your internal services, that's a massive security risk.
        rblatz 8y ago
        Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
        zAy0LfpBZLC8mAC 8y ago
        Why would all your services have to be hosted in house and why would it prevent you from "exposing internal services" (I mean, apart from the fact that they kindof aren't internal services anymore from that point on)? For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an external CA for external services? I mean, it just doesn't, that's how I run stuff: Purely internal stuff runs on internal CA, stuff that needs to face the public somehow runs on globally recognized CAs. And it's mostly trivial to switch services from one to the other - or to just run two endpoints, one using the internal CA, one using an external CA. It seems to me like your problem wasn't your own root CA, your problem was that your services were incompatible with external CAs for some reason, among them probably your private DNS root? But that isn't a reason why you should put your internal services at risk from mismanaged public CAs, that's simply a reason why you should use a global domain and support provisioning of certificates from external CAs.
  - wil421 8y ago
    Why? It you are testing applications in a dev/test system that is only a available on the company VPN then how can you get burned? Sure it’s annoying clicking through browser warnings but if it’s not public facing I don’t see the danger.
    - rblatz 8y ago
      Just hope you never need an external system, or a cloud hosted service to talk to your dev/test environments. It’s so cheap and easy to do it right that it just doesn’t make sense to do it the other way.
avian 8y ago
I run some services for my private use. It's crazy that I need to have them certified by some third-party over-seas CA since I can't get my own devices to trust my own certificates. We're not at that point yet, but running your own trust root is getting quite annoying. For example, Android constantly nags about "network might be monitored" when custom certificates are installed.
- pritambaral 8y ago
  > Android constantly nags about "network might be monitored" when custom certificates are installed. This is why I baked my home network certificate into the system trust store when building the ROM.
  - magic-chicken 8y ago
    What tools / guide did you use to accomplish this (building the ROM AND adding your certificate) ?
    - StillBored 8y ago
      (maybe not what you were asking) But for beginners there are some pretty nice LineageOs build guides floating around: For specific pieces of hardware: https://wiki.lineageos.org/build_guides.html https://wiki.lineageos.org/build_guides.html Generic instructions: https://forum.xda-developers.com/chef-central/android/how-to-build-lineageos-14-1-t3551484 https://forum.xda-developers.com/chef-central/android/how-to... As far as changing the certs, I know offhand to do it with a couple random linux distro's but i'm not 100% sure for android, you might just try searching the repo for the default certs then looking at how they are built into the image and tweaking that.
- otterlicious 8y ago
  Android constantly nags about "network might be monitored" when custom certificates are installed. It won't if you add name constraints to your root certificate (because then it can't be used for blanket monitoring).
tialaramex 8y ago
Nobody will issue Sennheiser a certificate for this purpose. Every so often a company abuses a cert they were issued to do what Sennheiser wanted to achieve here (local loopback HTTPS) and when they're caught the cert is revoked and they get a slap on the wrist. Blizzard is a recent example. The Right Thing (TM) is to not do HTTPS, a modern web browser is supposed to conclude that ::1 and 127.0.0.1 are secure without HTTPS since there is no possibility of a "man in the middle" of your own computer's loopback.
- plopz 8y ago
  Blizzard ended up doing it the right way. https://twitter.com/taviso/status/939634523137966080 https://twitter.com/taviso/status/939634523137966080 https://news.ycombinator.com/item?id=15982161 https://news.ycombinator.com/item?id=15982161
- kilburn 8y ago
  If you want an arbitrary (thus https based) website to be able to communicate with a localhost server using websockets you are forced to use https on the localhost server. This is because the browser won't connect to non-secure websockets from an https website, even if the websocket is to localhost. The actual right thing to do is to generate a private key and certificate (for a specific, public name you point to 127.0.0.1) during the software installation and add the latter to the trusted store. Now you don't have this vulnerability because each computer has a different trusted certificate with a different key, so a random attacker cannot just use the key they got to spy on other users.
AndyMcConachie 8y ago
Stupid question. Who should have the ability to install root CA certs? I like using HTTPS instead of HTTP, so I need some installed. Who should be responsible for managing them? And before you say the CABF, they're ultimatately not the ones who decide what gets installed on your computer. The answer to that question is much more complicated.
jerf 8y ago
There was never a good reason to install a root certificate for the purpose of speaking securely to your own gear or web services. In that case, you don't need to add them to the root trust store, you just need to create an SSL context that has those certificates set as trusted. However, the problem is, nobody understands SSL properly. Among the people who don't understand SSL properly is, alas, a number of people writing SSL libraries. Not the actual SSL libraries like OpenSSL, but all the surrounding libraries to make it "easy to use", which includes libraries that try to make HTTP easy to use and abstract the difference between HTTP and HTTPS. Pretty much every "ease of use" library I have ever seen accomplishes its ease of use by dropping features from the underlying SSL support, but it's clear they often don't understand why those features were there and the consequences of dropping them. I have a particular case where I've got some Perl code that is literally 4 levels deep in "SSL ease of use" code, with pretty much every layer dropping SSL features along the way (even the base level Net::SSLeay is missing a lot of stuff once you go beyond the basics, and it only gets worse as the stack gets higher). Once I had to poke support for a certain feature all the way down through the entire stack because it got dropped really early. So what you need to do in this case is create your own root store of trust, and then stick your own certs in there from some .pems or something, and then use that to initialize SSL on your connection. But it's complicated to do that at the base level of a lot of SSL libraries, and this is often one of the first features to be "abstracted away" by support libraries, and a lot of HTTP libraries end up trying to "abstract away" SSL so thoroughly that they don't even have parameters to control the SSL elements of the connection, and if they do, they have some ad-hoc selection of random bits that someone once needed, rather than comprehensive support. The upshot is that I'd consider it likely that they were using one of these libraries, and the only way they could see to get their certificates trusted was to stick them in the default root store, because that's the only thing that would work with such libraries. You can also find web pages and such recommending this approach. It's also possible they just came across one of these web pages or something and put stuff in the root without realizing what it really meant, even though their library allowed them to do everything I said, because it's way easier to slam something into the default trust store than write the code to create your own at run time. (It ought to be easy to write that code. The rather nice Go TLS library makes it almost as easy as I say it is; create cert store, add certificate, set that as your root trust, modulo a bit of error handling it really is just about that many lines of code. But the "ease of use" libraries can really get in the way, when the people adding the "ease of use" abstractions themselves don't understand what that means, or why you might want/need it, or how to make it easy.)

tyingq 8y ago

Corporate MITM proxies, like Forcepoint/Websense. For loose definitions of "legitimate."

zorked 8y ago

It's perfectly normal to install new root certificates - for example, so that a company can sign internal websites (or for MITM proxies). It's incredibly shady to have random software install into your trust store.

rblatz 8y ago
As someone that has been burned by self signed internal only sites. Take the extra 15 minutes and get a proper cert, and domain name for your internal sites. It can save a massive amount of pain later.
- zAy0LfpBZLC8mAC 8y ago
  burned how exactly?
  - hannasanarion 8y ago
    It can be a real pain in the butt to go up and down the whole stack and reconfigure every library and application that might detect a insecure connection and bail. Need several independent webapps to communicate? Hoo boy.
  - rblatz 8y ago
    In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to clean the mess completely up.
    - zAy0LfpBZLC8mAC 8y ago
      Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good idea as well. Relying on an external CA for internal services just creates risks of both availability and security. If you need an external CA to set up or continue operating internal services, that is an availability risk, and if you trust the whole standard set of root CAs for all of your internal services, that's a massive security risk.
      - rblatz 8y ago
        Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
        zAy0LfpBZLC8mAC 8y ago
        Why would all your services have to be hosted in house and why would it prevent you from "exposing internal services" (I mean, apart from the fact that they kindof aren't internal services anymore from that point on)? For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an external CA for external services? I mean, it just doesn't, that's how I run stuff: Purely internal stuff runs on internal CA, stuff that needs to face the public somehow runs on globally recognized CAs. And it's mostly trivial to switch services from one to the other - or to just run two endpoints, one using the internal CA, one using an external CA. It seems to me like your problem wasn't your own root CA, your problem was that your services were incompatible with external CAs for some reason, among them probably your private DNS root? But that isn't a reason why you should put your internal services at risk from mismanaged public CAs, that's simply a reason why you should use a global domain and support provisioning of certificates from external CAs.
- wil421 8y ago
  Why? It you are testing applications in a dev/test system that is only a available on the company VPN then how can you get burned? Sure it’s annoying clicking through browser warnings but if it’s not public facing I don’t see the danger.
  - rblatz 8y ago
    Just hope you never need an external system, or a cloud hosted service to talk to your dev/test environments. It’s so cheap and easy to do it right that it just doesn’t make sense to do it the other way.

avian 8y ago

I run some services for my private use. It's crazy that I need to have them certified by some third-party over-seas CA since I can't get my own devices to trust my own certificates. We're not at that point yet, but running your own trust root is getting quite annoying. For example, Android constantly nags about "network might be monitored" when custom certificates are installed.

pritambaral 8y ago
> Android constantly nags about "network might be monitored" when custom certificates are installed. This is why I baked my home network certificate into the system trust store when building the ROM.
- magic-chicken 8y ago
  What tools / guide did you use to accomplish this (building the ROM AND adding your certificate) ?
  - StillBored 8y ago
    (maybe not what you were asking) But for beginners there are some pretty nice LineageOs build guides floating around: For specific pieces of hardware: https://wiki.lineageos.org/build_guides.html https://wiki.lineageos.org/build_guides.html Generic instructions: https://forum.xda-developers.com/chef-central/android/how-to-build-lineageos-14-1-t3551484 https://forum.xda-developers.com/chef-central/android/how-to... As far as changing the certs, I know offhand to do it with a couple random linux distro's but i'm not 100% sure for android, you might just try searching the repo for the default certs then looking at how they are built into the image and tweaking that.
otterlicious 8y ago
Android constantly nags about "network might be monitored" when custom certificates are installed. It won't if you add name constraints to your root certificate (because then it can't be used for blanket monitoring).

tialaramex 8y ago

Nobody will issue Sennheiser a certificate for this purpose. Every so often a company abuses a cert they were issued to do what Sennheiser wanted to achieve here (local loopback HTTPS) and when they're caught the cert is revoked and they get a slap on the wrist. Blizzard is a recent example. The Right Thing (TM) is to not do HTTPS, a modern web browser is supposed to conclude that ::1 and 127.0.0.1 are secure without HTTPS since there is no possibility of a "man in the middle" of your own computer's loopback.

plopz 8y ago
Blizzard ended up doing it the right way. https://twitter.com/taviso/status/939634523137966080 https://twitter.com/taviso/status/939634523137966080 https://news.ycombinator.com/item?id=15982161 https://news.ycombinator.com/item?id=15982161
kilburn 8y ago
If you want an arbitrary (thus https based) website to be able to communicate with a localhost server using websockets you are forced to use https on the localhost server. This is because the browser won't connect to non-secure websockets from an https website, even if the websocket is to localhost. The actual right thing to do is to generate a private key and certificate (for a specific, public name you point to 127.0.0.1) during the software installation and add the latter to the trusted store. Now you don't have this vulnerability because each computer has a different trusted certificate with a different key, so a random attacker cannot just use the key they got to spy on other users.

AndyMcConachie 8y ago

Stupid question. Who should have the ability to install root CA certs? I like using HTTPS instead of HTTP, so I need some installed. Who should be responsible for managing them? And before you say the CABF, they're ultimatately not the ones who decide what gets installed on your computer. The answer to that question is much more complicated.

jerf 8y ago

There was never a good reason to install a root certificate for the purpose of speaking securely to your own gear or web services. In that case, you don't need to add them to the root trust store, you just need to create an SSL context that has those certificates set as trusted. However, the problem is, nobody understands SSL properly. Among the people who don't understand SSL properly is, alas, a number of people writing SSL libraries. Not the actual SSL libraries like OpenSSL, but all the surrounding libraries to make it "easy to use", which includes libraries that try to make HTTP easy to use and abstract the difference between HTTP and HTTPS. Pretty much every "ease of use" library I have ever seen accomplishes its ease of use by dropping features from the underlying SSL support, but it's clear they often don't understand why those features were there and the consequences of dropping them. I have a particular case where I've got some Perl code that is literally 4 levels deep in "SSL ease of use" code, with pretty much every layer dropping SSL features along the way (even the base level Net::SSLeay is missing a lot of stuff once you go beyond the basics, and it only gets worse as the stack gets higher). Once I had to poke support for a certain feature all the way down through the entire stack because it got dropped really early. So what you need to do in this case is create your own root store of trust, and then stick your own certs in there from some .pems or something, and then use that to initialize SSL on your connection. But it's complicated to do that at the base level of a lot of SSL libraries, and this is often one of the first features to be "abstracted away" by support libraries, and a lot of HTTP libraries end up trying to "abstract away" SSL so thoroughly that they don't even have parameters to control the SSL elements of the connection, and if they do, they have some ad-hoc selection of random bits that someone once needed, rather than comprehensive support. The upshot is that I'd consider it likely that they were using one of these libraries, and the only way they could see to get their certificates trusted was to stick them in the default root store, because that's the only thing that would work with such libraries. You can also find web pages and such recommending this approach. It's also possible they just came across one of these web pages or something and put stuff in the root without realizing what it really meant, even though their library allowed them to do everything I said, because it's way easier to slam something into the default trust store than write the code to create your own at run time. (It ought to be easy to write that code. The rather nice Go TLS library makes it almost as easy as I say it is; create cert store, add certificate, set that as your root trust, modulo a bit of error handling it really is just about that many lines of code. But the "ease of use" libraries can really get in the way, when the people adding the "ease of use" abstractions themselves don't understand what that means, or why you might want/need it, or how to make it easy.)