Re: [gentoo-user] app-misc/ca-certificates
On Tue, Jun 1, 2021 at 11:29 PM Rich Freeman wrote: > On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote: > >> > >> And another "wondering" - all the warnings about trusting self signed > >> certs seem a bit self serving. Yes, they are trying to certify who you > >> are, but at the expense of probably allowing access to your > >> communications by "authorised parties" (such as commercial entities > >> purchasing access for MITM access - e.g. certain router/firewall > >> companies doing deep inspection of SSL via resigning or owning both end > >> points). > > > > AFAIK in an enterprise MITM works by having a local CA added to the cert > stores of the workstation fleet, and having that CA auto generate the certs > for MITM. That didn't work with certificate pinning, but pinning has been > deprecated. > > So, I don't know all the ways that pinning is implemented, but if > you're talking about using MITM to snoop on enterprise devices on the > enterprise network I'd think that pinning wouldn't be an issue, > because you control the devices from cradle to grave. Just ensure the > pinned certificates are the ones that let you MITM the connections. > After seeing Grant's mention of CAA records I think I may have conflated pinning with them, or perhaps there were some special controls in Chrome to check that google certs were issued by the correct CA? Sorry i'm not clear on this now (and may have never been).
Re: [gentoo-user] app-misc/ca-certificates
On 6/2/21 1:48 AM, Fannys wrote: Tech should be based on tech. Not faith and trust on the other party. That's where detection of breach of trust comes into play. Thus DNSSEC and things related. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On 6/2/21 1:21 AM, J. Roeleveld wrote: Do you know which extensions add this? I don't remember exactly (they weren't compatible with Firefox 78) but from memory, they were from the CZ NIC operator. They have many things related to this. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On June 2, 2021 1:51:06 AM UTC, Grant Taylor wrote: >On 6/1/21 3:38 PM, Michael Orlitzky wrote: >> *Any* CA can just generate a new key and sign the corresponding >> certificate. > >This is where what can /technically/ be done diverges from what is >/allowed/ to be done. > >CAs adhering to the CA/B Forum's requirements on CAA records mean that >they aren't allowed to issue a certificate for a domain that doesn't >list them in the CAA record. > >If a CA violates the CAA record requirement, then the CA has bigger >issues and will be subject to distrusting in mass. > >Certificate Transparency logs make it a lot easier to identify if such >shenanigans are done. -- I think that the CA/B Forum is also >requiring >C.T. Logs. > >Also, CAs /should/ *NOT* be generating keys. The keys should be >generated by the malicious party trying to pull the shenanigans that >you're talking about. > >> All browsers will treat their fake certificate corresponding to the >> fake key on their fake web server as completely legitimate. The >"real" >> original key that you generated has no special technical properties >> that distinguish it. > >Not /all/ browsers. I know people that have run browser extensions to >validate the TLS certificate that they receive against records >published >via DANE in DNS, which is protected by DNSSEC. So it's effectively >impossible for a rogue CA and malicious actor to violate that chain of >trust in a way that can't be detected and acted on. From my understanding its all based on trust and faith unless I take steps from my side. That doesnt seem very safe. Tech should be based on tech. Not faith and trust on the other party. Marinus pEpkey.asc Description: application/pgp-keys
Re: [gentoo-user] app-misc/ca-certificates
On Wednesday, June 2, 2021 12:28:49 AM CEST Fannys wrote: > On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" wrote: > >On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote: > >> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote > >> > >> > 125 config files in /etc/ssl/certs needs update. > >> > > >> > For certificates I would expect the old and invalid ones to be > > > >replaced > > > >> > by newer ones without user intervention. > >> > > >> Looking through them is "interesting". There seem to be a lot of > >> > >> /etc/ssl/certs/.0 files, where "?" is either a random number > > > >or > > > >> a lower case letter. These all seem to be symlinks to > >> /etc/ssl/certs/.pem. Each of those files is in turn a > >> symlink to /usr/share/ca-certificates/mozilla/.crt. How > > > >much > > > >> do we trust China? There are a couple of certificates in there named > >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and > >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any > >> other suspicious regimes in there? > > > >I've always wondered about the amount of CAs that are auto-trusted on > >any > >system. Including several from countries with serious human rights > >issues. > > > >I could do with a tool where I can easily select which CAs to trust > >based on > >country. > > > >-- > >Joost > > Is there actually any tool that can let me pick my certificates? > If i go and start deleting randomly certificates from regimes i dont like > will there be any "breaking change"? I suppose firefox uses its own > certificate store though. If the CA is removed from your system/app/..., any key signed by that CA will be seen as "untrusted" (treated as if self-signed) and you need to go through the usual hoops to allow that certificate to be used. -- Joost
Re: [gentoo-user] app-misc/ca-certificates
On Wednesday, June 2, 2021 3:51:06 AM CEST Grant Taylor wrote: > On 6/1/21 3:38 PM, Michael Orlitzky wrote: > > All browsers will treat their fake certificate corresponding to the > > fake key on their fake web server as completely legitimate. The "real" > > original key that you generated has no special technical properties > > that distinguish it. > > Not /all/ browsers. I know people that have run browser extensions to > validate the TLS certificate that they receive against records published > via DANE in DNS, which is protected by DNSSEC. So it's effectively > impossible for a rogue CA and malicious actor to violate that chain of > trust in a way that can't be detected and acted on. Do you know which extensions add this?
Re: [gentoo-user] app-misc/ca-certificates
On 6/1/21 3:38 PM, Michael Orlitzky wrote: *Any* CA can just generate a new key and sign the corresponding certificate. This is where what can /technically/ be done diverges from what is /allowed/ to be done. CAs adhering to the CA/B Forum's requirements on CAA records mean that they aren't allowed to issue a certificate for a domain that doesn't list them in the CAA record. If a CA violates the CAA record requirement, then the CA has bigger issues and will be subject to distrusting in mass. Certificate Transparency logs make it a lot easier to identify if such shenanigans are done. -- I think that the CA/B Forum is also requiring C.T. Logs. Also, CAs /should/ *NOT* be generating keys. The keys should be generated by the malicious party trying to pull the shenanigans that you're talking about. All browsers will treat their fake certificate corresponding to the fake key on their fake web server as completely legitimate. The "real" original key that you generated has no special technical properties that distinguish it. Not /all/ browsers. I know people that have run browser extensions to validate the TLS certificate that they receive against records published via DANE in DNS, which is protected by DNSSEC. So it's effectively impossible for a rogue CA and malicious actor to violate that chain of trust in a way that can't be detected and acted on. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On 1/6/21 9:29 pm, Rich Freeman wrote: > On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote: >>> And another "wondering" - all the warnings about trusting self signed >>> certs seem a bit self serving. Yes, they are trying to certify who you >>> are, but at the expense of probably allowing access to your >>> communications by "authorised parties" (such as commercial entities >>> purchasing access for MITM access - e.g. certain router/firewall >>> companies doing deep inspection of SSL via resigning or owning both end >>> points). >> AFAIK in an enterprise MITM works by having a local CA added to the cert >> stores of the workstation fleet, and having that CA auto generate the certs >> for MITM. That didn't work with certificate pinning, but pinning has been >> deprecated. > So, I don't know all the ways that pinning is implemented, but if > you're talking about using MITM to snoop on enterprise devices on the > enterprise network I'd think that pinning wouldn't be an issue, > because you control the devices from cradle to grave. Just ensure the > pinned certificates are the ones that let you MITM the connections. > > Now, if your organization has some sort of guest network for > non-enterprise devices then pinning would obviously block MITM of > connections made by those devices. Really though I'm not sure you'd > want to be snooping stuff like this - it seems like more legal > headaches than it is worth. You want to sniff your OWN traffic for > IDS/etc or other unauthorized use, and since you're sniffing traffic > from devices you own you don't have the same legal issues (I won't say > no legal issues, but certainly monitoring your own devices is very > different from monitoring those you don't own). You shouldn't even be > allowing uncontrolled devices on those networks in the first place. > If you want to detect unauthorized devices MITM isn't really the best > solution - just use positive authentication of known-good devices > up-front and anything that doesn't pass that test is treated as a > threat and shouldn't even be able to send traffic. When discussing what traffic is looked at in an educational setting it looked like the system examined everything except mainline banking URL's For OpenVPN through a MiTM SSL proxy: Double wrap in SSL - outer one uses their cert so it does not fail that test - inner one uses your self signed cert for OpenVPN running on port 443 TCP. At the destination use the sslh multiplexor to divert SSL to stunnel/second sslh instance etc. to strip the SSL wrapping appropriately. Works using a combination of proxytunnel on the Windows side and stunnel on the linux end if needed - very flexible). There are are a few other enhancements for pinholing more difficult sites. Performance is entirely adequate for a road warrior setup when travelling (via a Raspberry Pi AP). I have had to get a lot more sophisticated than back in the day when httptunnel was all that was needed :) BillK
Re: [gentoo-user] app-misc/ca-certificates
On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" wrote: >On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote: >> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote >> >> > 125 config files in /etc/ssl/certs needs update. >> > >> > For certificates I would expect the old and invalid ones to be >replaced >> > by newer ones without user intervention. >> >> Looking through them is "interesting". There seem to be a lot of >> /etc/ssl/certs/.0 files, where "?" is either a random number >or >> a lower case letter. These all seem to be symlinks to >> /etc/ssl/certs/.pem. Each of those files is in turn a >> symlink to /usr/share/ca-certificates/mozilla/.crt. How >much >> do we trust China? There are a couple of certificates in there named >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any >> other suspicious regimes in there? > >I've always wondered about the amount of CAs that are auto-trusted on >any >system. Including several from countries with serious human rights >issues. > >I could do with a tool where I can easily select which CAs to trust >based on >country. > >-- >Joost Is there actually any tool that can let me pick my certificates? If i go and start deleting randomly certificates from regimes i dont like will there be any "breaking change"? I suppose firefox uses its own certificate store though. Marinus pEpkey.asc Description: application/pgp-keys
Re: [gentoo-user] app-misc/ca-certificates
On Tue, 2021-06-01 at 15:25 -0600, Grant Taylor wrote: > > The proper way configure certificates is: > > 1) Create a key on the local server. > 2) Create a Certificate Signing Request (a.k.a. CSR) which references, > but does not include, the key. > 3) As a CA to sign the CSR. > 4) Use the certificate from the CA. > > The important thing is that the key, which is integral to the encryption > *NEVER* *LEAVES* *YOUR* *CONTROL*! > *Any* CA can just generate a new key and sign the corresponding certificate. All browsers will treat their fake certificate corresponding to the fake key on their fake web server as completely legitimate. The "real" original key that you generated has no special technical properties that distinguish it.
Re: [gentoo-user] app-misc/ca-certificates
On 5/31/21 11:15 PM, William Kenworthy wrote: And another "wondering" - all the warnings about trusting self signed certs seem a bit self serving. No, it's not self serving. Considerably more people than public certificate authorities bemoan self signed certificates. Consider this: 1) Your web site uses a self signed certificate and you have trained users to blindly accept and trust the certificate presented to them. 2) Someone decides to intercept the traffic and presents a different self signed certificate to the end users while proxying the traffic on to you. 3) Your end users have no viable way to differentiate between your self signed certificate and the intercepting self signed certificate. Without someone - which you trust - vouching for the identity of the party that you're connecting to, you have no way to know that you are actually connecting to the partying that you are intending to connect to. Yes, they are trying to certify who you are, but at the expense of probably allowing access to your communications by "authorised parties" Nope. Not at all. (Presuming that it's done properly. More below.) The /only/ thing that the certificate does / provides is someone - whom end users supposedly trust - vouching that you are who you say they are. The CA has nothing in the actual communications path. Thus they can't see the traffic if they want to. The proper way configure certificates is: 1) Create a key on the local server. 2) Create a Certificate Signing Request (a.k.a. CSR) which references, but does not include, the key. 3) As a CA to sign the CSR. 4) Use the certificate from the CA. The important thing is that the key, which is integral to the encryption *NEVER* *LEAVES* *YOUR* *CONTROL*! Thus there is no way that a CA is even capable of getting in the middle of the end-to-end communications between you and your client. There have been some CAs in the past that would try to do everything on their server. But in doing so, they violate the security model. Don't use those CAs. *YOU* /must/ generate the key /locally/. Anything else is broken security. (such as commercial entities purchasing access for MITM access - e.g. certain router/firewall companies doing deep inspection of SSL via resigning or owning both end points). This is actually exceedingly difficult to do, at least insofar as decryption and re-encrypting the traffic. Certificate Transparency logs help ensure that a CA doesn't ... inadvertantly ... issue a certificate that they should not. Or at least it makes it orders of magnitude easier to identify and detect when such ... mistakes happen. There is also the Certificate Authority Authorization record that you can put in DNS that authorizes which CA(s) can issue certificates for a domain. A few years ago we passed the deadline where all CAs had to adhere to the CAA record. As in the Certificate Authority / Browser forum / consortium / term??? has non-renewed anybody who wasn't adhering to CAA. This is water so far under the bridge that it's over the waterfall, out to ocean, evaporated, and is raining down again. Also, DNSSEC protects DNS in that it makes it possible to authenticate the information you receive. Thus you can detect when things aren't authenticated and you know they should be. If its only your own communications and not with a third, commercial party self signed seems a lot more secure. Nope. 3rd parties don't have access to the encrypted communications. The only thing they have access to is saying if you are you or not. Yes, that's Bob over there in the corner. But I have no idea what he's talking about b/c MATH. Note the words "signed" and "signing". A Certificate Authority signs a certificate signing request, thus vouching for the identity of the entity submitting the CSR. You obviously can sign your own CSR. That's what a self-signed certificate comes from. But you have nobody vouching for who the far entity is, much less who vouched for them. Spekaing of who vouched for them, and how do we trust them? That's where the hashes in /etc/ssl (or wherever it is) come into play. Your system has a public key for /trusted/ root CAs. Thus when your system sees a certificate signed by a CA, it computes the hash, looks for the public key as the hash file on your local system. If the file exists and all the math passes, then the root certificate is trusted. If the root certificate is trusted, then your system will trust the certificate that the CA is vouching for. This is all ... something ... having to do with who is vouching for whom and do you trust the vouching party or not. But at no time does a CA have access to the encrypted communications. As long as things were done properly in that the keys were generated locally. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On 5/29/21 12:26 AM, Walter Dnes wrote: Looking through them is "interesting". There seem to be a lot of /etc/ssl/certs/.0 files, where "?" is either a random number or a lower case letter. They aren't random at all. They are a fingerprint (hash) of signing (?) certificates. The fingerprint is generated in a deterministic manner. The sym-links (or hard links) are a convenient way to associate a hash back to the cert file that it's representing. root@host# ln -s /path/to/cert /etc/ssl/certs/$(openssl x509 -noout -hash -in /path/to/cert) The hash is what things validating things use. They have no good way to determine what the file name would be. So they compute and look up the hash. You could name all the files with hashes. But that would make it quite annoying ~> difficult, impractical, bordering on impossible for a human to maintain. So, instead, the trusted root certificates are stored by a human friendly name and the hashes point to the file via a sym-link. These all seem to be symlinks to /etc/ssl/certs/.pem. Quite likely. Each of those files is in turn a symlink to/usr/share/ca-certificates/mozilla/.crt. Maybe / probably. Definitely for root certificates that are part of the Mozilla Security Suite. But it's definitely possible to have other root certificates through the same system. E.g. you run your own private / enterprise CA. Any other suspicious regimes in there? I'm confident that it depends on where you are in the world. Let's keep things apolitical and purely technical. -- Grant. . . . unix || die
Re: [gentoo-user] app-misc/ca-certificates
On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote: >> >> And another "wondering" - all the warnings about trusting self signed >> certs seem a bit self serving. Yes, they are trying to certify who you >> are, but at the expense of probably allowing access to your >> communications by "authorised parties" (such as commercial entities >> purchasing access for MITM access - e.g. certain router/firewall >> companies doing deep inspection of SSL via resigning or owning both end >> points). > > AFAIK in an enterprise MITM works by having a local CA added to the cert > stores of the workstation fleet, and having that CA auto generate the certs > for MITM. That didn't work with certificate pinning, but pinning has been > deprecated. So, I don't know all the ways that pinning is implemented, but if you're talking about using MITM to snoop on enterprise devices on the enterprise network I'd think that pinning wouldn't be an issue, because you control the devices from cradle to grave. Just ensure the pinned certificates are the ones that let you MITM the connections. Now, if your organization has some sort of guest network for non-enterprise devices then pinning would obviously block MITM of connections made by those devices. Really though I'm not sure you'd want to be snooping stuff like this - it seems like more legal headaches than it is worth. You want to sniff your OWN traffic for IDS/etc or other unauthorized use, and since you're sniffing traffic from devices you own you don't have the same legal issues (I won't say no legal issues, but certainly monitoring your own devices is very different from monitoring those you don't own). You shouldn't even be allowing uncontrolled devices on those networks in the first place. If you want to detect unauthorized devices MITM isn't really the best solution - just use positive authentication of known-good devices up-front and anything that doesn't pass that test is treated as a threat and shouldn't even be able to send traffic. -- Rich
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tue, Jun 1, 2021 at 8:16 AM Michael Orlitzky wrote: > > On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote: > > > > So what would you recommend for someone in the case Joost cites? I'm in that > > position, being a home user of a small network but no registered Internet > > name. > > > > A self-signed certificate combined with a browser extension that lets > you "pin" it. With pinning, you can keep your browser usable on the WWW > while still rejecting any forged certificates for your own hosts. The > end result works pretty much like SSH keys do. Can't really argue with this. However, for those who aren't completely following along it is probably worth pointing out that the way you're doing it is different from how 99.999% of the way the world is doing it. So, if you're talking about securing communications between hosts you control what mjo suggests is a much better solution than the standard solution (at least security-wise). There are probably better ways to do it, but not much that is standard. However, if you're working with others then that solution isn't such a good one, as it isn't really standard. That said, it isn't uncommon for more sophisticated companies to pin certificates from their partners so that a random CA can't do an end-run around security. I have vendors I work with who regularly send out notices of pending certificate changes to technical contacts to allow for this. Really though the entire SSL CA infrastructure needs a massive overhaul. Using something like DNSSEC as a trust root would be one way to go about it. Another might be to restrict the scope that CAs could sign within and have some way to automate that. Self-signed certs aren't a good solution for the average user and no SSL is an even worse one (at best it removes security theater, but at the cost of allowing attackers to not even bother with subverting the CA system, which opens up a lot more attacks). Right now you can browse using SSL to army.mil for the first time and in theory your browser won't complain if the certificate is signed by the PLA... -- Rich
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
Karl: > Michael Orilitzky: Sorry, I mistyped, it should be: Peter Humphrey > ... > > * The LetsEncrypt certificates expire after three months, as opposed > > to 10+ years for a self-signed certificate. You're supposed to > > automate this... by running a script as root that takes input from > > the web? I'd rather not do that. > > You can run most part of it as an unpriviliged user, here is my crontab: > 0 0 1 * * acme/usr/local/sbin/acme_update.sh > 10 01 * * rootcat /etc/acme-tiny/domain.key > /var/acme-tiny/signed_chain.crt > /etc/lighttpd/server.pem > 20 01 * * root/etc/init.d/lighttpd restart > > One could add a check to make sure that the downloaded crt is sensible. > > > * LetsEncrypt verifies your identity over plain HTTP (like every other > > commercial CA), so it's all security theater in the first place. > ... > > Ack. Regards, /Karl Hammar
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
Michael Orilitzky: ... > * The LetsEncrypt certificates expire after three months, as opposed > to 10+ years for a self-signed certificate. You're supposed to > automate this... by running a script as root that takes input from > the web? I'd rather not do that. You can run most part of it as an unpriviliged user, here is my crontab: 0 0 1 * * acme/usr/local/sbin/acme_update.sh 10 01 * * rootcat /etc/acme-tiny/domain.key /var/acme-tiny/signed_chain.crt > /etc/lighttpd/server.pem 20 01 * * root/etc/init.d/lighttpd restart One could add a check to make sure that the downloaded crt is sensible. > * LetsEncrypt verifies your identity over plain HTTP (like every other > commercial CA), so it's all security theater in the first place. ... Ack. Regards, /Karl Hammar
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
Joost: > On Tuesday, June 1, 2021 12:44:47 PM CEST k...@aspodata.se wrote: ... [ about letsencrypt ] ... > It's not that easy to do it with internal-only systems as Let's Encrypt > requires the hostname to be known externally. > And there are plenty of devices you do not want the whole internet to know > about. Just use a celf-certified cert and add an exeption in the web browser, or set up your own CA, (I don't know how) and distribute its cert. Regards, /Karl Hammar
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tuesday, 1 June 2021 13:16:59 BST Michael Orlitzky wrote: > On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote: > > So what would you recommend for someone in the case Joost cites? I'm in > > that position, being a home user of a small network but no registered > > Internet name. > > A self-signed certificate combined with a browser extension that lets > you "pin" it. With pinning, you can keep your browser usable on the WWW > while still rejecting any forged certificates for your own hosts. The > end result works pretty much like SSH keys do. Thanks Michael. -- Regards, Peter.
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote: > > So what would you recommend for someone in the case Joost cites? I'm in that > position, being a home user of a small network but no registered Internet > name. > A self-signed certificate combined with a browser extension that lets you "pin" it. With pinning, you can keep your browser usable on the WWW while still rejecting any forged certificates for your own hosts. The end result works pretty much like SSH keys do.
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tuesday, 1 June 2021 12:40:28 BST Michael Orlitzky wrote: > On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote: > > It's not that easy to do it with internal-only systems as Let's Encrypt > > requires the hostname to be known externally. > > And there are plenty of devices you do not want the whole internet to know > > about. > > And in this situation LetsEncrypt does nothing but make security worse: > > * You have to trust the entire CA infrastructure rather than just your > own CA. Many of the CAs are not just questionable, but like the > governments of the USA and China, known to be engaged in large-scale > man-in-the-middle attacks. > > * The LetsEncrypt certificates expire after three months, as opposed > to 10+ years for a self-signed certificate. You're supposed to > automate this... by running a script as root that takes input from > the web? I'd rather not do that. > > * LetsEncrypt verifies your identity over plain HTTP (like every other > commercial CA), so it's all security theater in the first place. > > There are plenty of arguments against LE even for public sites, but for > private ones, it's a lot more clear-cut... So what would you recommend for someone in the case Joost cites? I'm in that position, being a home user of a small network but no registered Internet name. -- Regards, Peter.
Re: [gentoo-user] app-misc/ca-certificates
> > And another "wondering" - all the warnings about trusting self signed > certs seem a bit self serving. Yes, they are trying to certify who you > are, but at the expense of probably allowing access to your > communications by "authorised parties" (such as commercial entities > purchasing access for MITM access - e.g. certain router/firewall > companies doing deep inspection of SSL via resigning or owning both end > points). CAs who issue such dodgy certs tend to get booted from certificate stores, since they cannot be trusted. https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29 https://en.wikipedia.org/wiki/Certificate_Transparency helps keep CAs honest. The way i like to frame it is "any certificate should only be trusted as much as the *least* trustworthy CA in your certificate store" AFAIK in an enterprise MITM works by having a local CA added to the cert stores of the workstation fleet, and having that CA auto generate the certs for MITM. That didn't work with certificate pinning, but pinning has been deprecated. > If its only your own communications and not with a third, > commercial party self signed seems a lot more secure. > Yes, I imagine there are some circumstances where it would make sense to remove all the certs from your certificate store and then just add your local CA's cert. In this case, the least trustworthy CA in the store is your own :)
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote: > > It's not that easy to do it with internal-only systems as Let's Encrypt > requires the hostname to be known externally. > And there are plenty of devices you do not want the whole internet to know > about. > And in this situation LetsEncrypt does nothing but make security worse: * You have to trust the entire CA infrastructure rather than just your own CA. Many of the CAs are not just questionable, but like the governments of the USA and China, known to be engaged in large-scale man-in-the-middle attacks. * The LetsEncrypt certificates expire after three months, as opposed to 10+ years for a self-signed certificate. You're supposed to automate this... by running a script as root that takes input from the web? I'd rather not do that. * LetsEncrypt verifies your identity over plain HTTP (like every other commercial CA), so it's all security theater in the first place. There are plenty of arguments against LE even for public sites, but for private ones, it's a lot more clear-cut...
Re: Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
On Tuesday, June 1, 2021 12:44:47 PM CEST k...@aspodata.se wrote: > BillK: > ... > > > And another "wondering" - all the warnings about trusting self signed > > certs seem a bit self serving. Yes, they are trying to certify who you > > are, but at the expense of probably allowing access to your > > communications by "authorised parties" (such as commercial entities > > purchasing access for MITM access - e.g. certain router/firewall > > companies doing deep inspection of SSL via resigning or owning both end > > points). If its only your own communications and not with a third, > > commercial party self signed seems a lot more secure. > > ... > > You can use https://letsencrypt.org/ instead of a self-signed cert: > > Let's Encrypt is a free, automated, and open certificate authority > brought to you by the nonprofit Internet Security Research Group (ISRG). > > It was pretty simple to get it to work with > https://github.com/diafygi/acme-tiny It's not that easy to do it with internal-only systems as Let's Encrypt requires the hostname to be known externally. And there are plenty of devices you do not want the whole internet to know about. -- Joost
Letsencrypt (was Re: [gentoo-user] app-misc/ca-certificates)
BillK: ... > And another "wondering" - all the warnings about trusting self signed > certs seem a bit self serving. Yes, they are trying to certify who you > are, but at the expense of probably allowing access to your > communications by "authorised parties" (such as commercial entities > purchasing access for MITM access - e.g. certain router/firewall > companies doing deep inspection of SSL via resigning or owning both end > points). If its only your own communications and not with a third, > commercial party self signed seems a lot more secure. ... You can use https://letsencrypt.org/ instead of a self-signed cert: Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit Internet Security Research Group (ISRG). It was pretty simple to get it to work with https://github.com/diafygi/acme-tiny Regards, /Karl Hammar
Re: [gentoo-user] app-misc/ca-certificates
On 1/6/21 12:45 pm, J. Roeleveld wrote: > On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote: >> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote >> >>> 125 config files in /etc/ssl/certs needs update. >>> >>> For certificates I would expect the old and invalid ones to be replaced >>> by newer ones without user intervention. >> Looking through them is "interesting". There seem to be a lot of >> /etc/ssl/certs/.0 files, where "?" is either a random number or >> a lower case letter. These all seem to be symlinks to >> /etc/ssl/certs/.pem. Each of those files is in turn a >> symlink to /usr/share/ca-certificates/mozilla/.crt. How much >> do we trust China? There are a couple of certificates in there named >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and >> /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any >> other suspicious regimes in there? > I've always wondered about the amount of CAs that are auto-trusted on any > system. Including several from countries with serious human rights issues. > > I could do with a tool where I can easily select which CAs to trust based on > country. > > -- > Joost And another "wondering" - all the warnings about trusting self signed certs seem a bit self serving. Yes, they are trying to certify who you are, but at the expense of probably allowing access to your communications by "authorised parties" (such as commercial entities purchasing access for MITM access - e.g. certain router/firewall companies doing deep inspection of SSL via resigning or owning both end points). If its only your own communications and not with a third, commercial party self signed seems a lot more secure. Getting a bit OT, but interesting none the less. BillK Ref: https://checkthefirewall.com/blogs/fortinet/ssl-inspection https://us-cert.cisa.gov/ncas/alerts/TA17-075A
Re: [gentoo-user] app-misc/ca-certificates
On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote: > On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote > > > 125 config files in /etc/ssl/certs needs update. > > > > For certificates I would expect the old and invalid ones to be replaced > > by newer ones without user intervention. > > Looking through them is "interesting". There seem to be a lot of > /etc/ssl/certs/.0 files, where "?" is either a random number or > a lower case letter. These all seem to be symlinks to > /etc/ssl/certs/.pem. Each of those files is in turn a > symlink to /usr/share/ca-certificates/mozilla/.crt. How much > do we trust China? There are a couple of certificates in there named > /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and > /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any > other suspicious regimes in there? I've always wondered about the amount of CAs that are auto-trusted on any system. Including several from countries with serious human rights issues. I could do with a tool where I can easily select which CAs to trust based on country. -- Joost
Re: [gentoo-user] app-misc/ca-certificates
On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote > > 125 config files in /etc/ssl/certs needs update. > > For certificates I would expect the old and invalid ones to be replaced > by newer ones without user intervention. Looking through them is "interesting". There seem to be a lot of /etc/ssl/certs/.0 files, where "?" is either a random number or a lower case letter. These all seem to be symlinks to /etc/ssl/certs/.pem. Each of those files is in turn a symlink to /usr/share/ca-certificates/mozilla/.crt. How much do we trust China? There are a couple of certificates in there named /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_1.crt and /usr/share/ca-certificates/mozilla/Hongkong_Post_Root_CA_3.crt. Any other suspicious regimes in there? -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] app-misc/ca-certificates
125 config files in /etc/ssl/certs needs update. For certificates I would expect the old and invalid ones to be replaced by newer ones without user intervention. bb.zven
