Is there a way to make sure my government does not exchange SSL certificates?
I was recently wondering whether there exists a way to make sure my government is not exchanging SSL certificates in order to grab the traffic.
I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?
One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.
If that is not a possible case, what mechanism is preventing them from doing it?
tls certificates man-in-the-middle certificate-authority government
New contributor
add a comment |
I was recently wondering whether there exists a way to make sure my government is not exchanging SSL certificates in order to grab the traffic.
I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?
One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.
If that is not a possible case, what mechanism is preventing them from doing it?
tls certificates man-in-the-middle certificate-authority government
New contributor
3
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago
add a comment |
I was recently wondering whether there exists a way to make sure my government is not exchanging SSL certificates in order to grab the traffic.
I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?
One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.
If that is not a possible case, what mechanism is preventing them from doing it?
tls certificates man-in-the-middle certificate-authority government
New contributor
I was recently wondering whether there exists a way to make sure my government is not exchanging SSL certificates in order to grab the traffic.
I know almost all browsers are complaining in case of a self-signed certificate. But what prevents a government to issue their own keychain?
One can imagine compromising the repositories containing packages with CA certificates and then issuing their own certificate in order to decipher the traffic. All the traffic is going through government loyal tier 1 operator which also has monopoly rights on providing Internet access.
If that is not a possible case, what mechanism is preventing them from doing it?
tls certificates man-in-the-middle certificate-authority government
tls certificates man-in-the-middle certificate-authority government
New contributor
New contributor
edited 8 hours ago
Peter Mortensen
69049
69049
New contributor
asked 20 hours ago
roman
22317
22317
New contributor
New contributor
3
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago
add a comment |
3
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago
3
3
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago
add a comment |
4 Answers
4
active
oldest
votes
If your adversary is a powerful nation-state threat actor, web PKI will not protect you.
Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.
While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.
Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.
A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
|
show 6 more comments
Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.
This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).
Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.
There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.
There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.
At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.
It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.
add a comment |
It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.
If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.
To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).
New contributor
add a comment |
Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
roman is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200725%2fis-there-a-way-to-make-sure-my-government-does-not-exchange-ssl-certificates%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
If your adversary is a powerful nation-state threat actor, web PKI will not protect you.
Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.
While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.
Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.
A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
|
show 6 more comments
If your adversary is a powerful nation-state threat actor, web PKI will not protect you.
Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.
While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.
Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.
A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
|
show 6 more comments
If your adversary is a powerful nation-state threat actor, web PKI will not protect you.
Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.
While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.
Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.
A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.
If your adversary is a powerful nation-state threat actor, web PKI will not protect you.
Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:
- Government of France
- Government of Hong Kong (SAR), Hongkong Post
- Government of Japan, Ministry of Internal Affairs and Communications
- Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
- Government of Spain (CAV), Izenpe S.A.
- Government of The Netherlands, PKIoverheid
- Government of Taiwan, Government Root Certification Authority (GRCA)
- Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.
While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.
Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.
A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.
edited 3 hours ago
answered 19 hours ago
forest
32.4k15103110
32.4k15103110
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
|
show 6 more comments
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
7
7
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
"Once it has seen greater adoption" FYI, Certificate transparency has ~100% adoption as of last year. Chrome won't even trust new certificates that aren't logged in CT anymore. (Though I suppose it will still be possible for another year for a malicious CA to backdate certs to get around the requirement.)
– Ajedi32
13 hours ago
4
4
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
"Nothing is preventing them from issuing their own certificate" - this is not fully true. Browsers like Chrome and Firefox have built-in certificate pinning for critical domains (google, facebook, mozilla, ....) and these will detect if a different CA than expected has issued a certificate for these sites. This is for example how the use of fake certificates for Google in Iran got detected when DigiNotar got hacked. While certificate pinning (and checking of CT) gets disabled for explicitly added CA to facilitate legal SSL interception it gets not disabled for the builtin CA.
– Steffen Ullrich
12 hours ago
3
3
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
Apart from certificate pinning any builtin CA which wrongly issues certificates risks to get quickly removed from the CA store of the browsers or to get the specific sub-CA banned. This happend several times in the past know (DigiNotar, Starcom, WoSign, Symantec) and it is unlikely that government-run CA did not get the message. I doubt that these CA will risk to get permanently banned. I find it more likely that the governments officially mandates the import of specific CA by their citizens to allow SSL interception, which has the nice side effect to disable pinning and CT too.
– Steffen Ullrich
12 hours ago
1
1
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
It may be worth noting that the US is attempting to build a limited-scope PKI that conforms to Mozilla's sensibilities. If I understand correctly, it is accepting public comment.
– Michael
10 hours ago
3
3
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
Once caught being abused, government CAs will surely get distrusted like any other. The result will probably be permanent loss of reputation of the government as a certificate signer.
– Joshua
9 hours ago
|
show 6 more comments
Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.
This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).
Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.
There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.
There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.
At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.
It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.
add a comment |
Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.
This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).
Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.
There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.
There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.
At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.
It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.
add a comment |
Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.
This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).
Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.
There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.
There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.
At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.
It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.
Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.
This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).
Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.
There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.
There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.
At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.
It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.
answered 19 hours ago
Steffen Ullrich
114k13197260
114k13197260
add a comment |
add a comment |
It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.
If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.
To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).
New contributor
add a comment |
It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.
If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.
To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).
New contributor
add a comment |
It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.
If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.
To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).
New contributor
It is indeed a risk and if you're going to do something that requires "real" security, let's say something like exchanging nuclear bomb codes, it is a real issue. Then again it's not the greater issue. The actors the attack passes through are not the government directly but CAs. A government always has access to the simple rubber-hose attack so this is always going to be an issue as long as the CAs will be public entities subject to the rule of law (because that will make them subject to one or more governments and thus sensible to pressures or plain old violence). As long as this attack is viable the more refined certificate manipulations are pretty useless, they could force CAs to help them (and keep the silence about it) even if they would not be CAs themselves.
If you need a higher level of confidence I would suggest turning to different approaches to communication involving also (but not only) steganography and side channels to reduce the visibility of your communications and thus reduce the probability to suffer attacks.
To delve into the situation a bit more the idea that a CA can exhibit proof of correctness of its certificates is not yet very popular but it could maybe be possible in a blockchain system. It would probably require significantly more calculations and so I doubt it's viable without some adjustments from the current industry. And even then governments have a very big say in what cryptographic primitives are secure so they could taint the very methods used to issue certificates, for example, I would like to refer you to the NSA's Bullrun program and for a more detailed example to the Dual_EC_DRBG backdoor theorized by Bruce Schneier and Niels Ferguson and later confirmed by Edward Snowden (an argument that I had the occasion to face during my studies before it was confirmed, Dual_EC_DRBG is potentially secure but you've got to generate the curves used in the cryptographic primitive yourself, otherwise you're essentially trusting the NSA to give you good private keys notice that this is not always the case with other algorithms).
New contributor
edited 11 hours ago
schroeder♦
73.3k29160195
73.3k29160195
New contributor
answered 11 hours ago
user3341700
311
311
New contributor
New contributor
add a comment |
add a comment |
Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.
add a comment |
Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.
add a comment |
Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.
Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.
answered 8 hours ago
R..
4,54711418
4,54711418
add a comment |
add a comment |
roman is a new contributor. Be nice, and check out our Code of Conduct.
roman is a new contributor. Be nice, and check out our Code of Conduct.
roman is a new contributor. Be nice, and check out our Code of Conduct.
roman is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f200725%2fis-there-a-way-to-make-sure-my-government-does-not-exchange-ssl-certificates%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
It is not unrealistic scenario. For example, in 2016, Kazakhstan government made attempts to sniff every user's TLS traffic: bugzilla.mozilla.org/show_bug.cgi?id=1229827, bugzilla.mozilla.org/show_bug.cgi?id=1232689. AFAIK, all these attempts failed in this particular case, but there is a chance for government to jump into trust list. Also, some non-democratic countries may force the use their root CAs on a law basis
– Crypt32
19 hours ago