| 1 |
> |
| 2 |
> And another "wondering" - all the warnings about trusting self signed |
| 3 |
> certs seem a bit self serving. Yes, they are trying to certify who you |
| 4 |
> are, but at the expense of probably allowing access to your |
| 5 |
> communications by "authorised parties" (such as commercial entities |
| 6 |
> purchasing access for MITM access - e.g. certain router/firewall |
| 7 |
> companies doing deep inspection of SSL via resigning or owning both end |
| 8 |
> points). |
| 9 |
|
| 10 |
|
| 11 |
CAs who issue such dodgy certs tend to get booted from certificate stores, |
| 12 |
since they cannot be trusted. |
| 13 |
https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29 |
| 14 |
|
| 15 |
https://en.wikipedia.org/wiki/Certificate_Transparency helps keep CAs |
| 16 |
honest. |
| 17 |
|
| 18 |
The way i like to frame it is "any certificate should only be trusted as |
| 19 |
much as the *least* trustworthy CA in your certificate store" |
| 20 |
|
| 21 |
AFAIK in an enterprise MITM works by having a local CA added to the cert |
| 22 |
stores of the workstation fleet, and having that CA auto generate the certs |
| 23 |
for MITM. That didn't work with certificate pinning, but pinning has been |
| 24 |
deprecated. |
| 25 |
|
| 26 |
|
| 27 |
> If its only your own communications and not with a third, |
| 28 |
> commercial party self signed seems a lot more secure. |
| 29 |
> |
| 30 |
|
| 31 |
Yes, I imagine there are some circumstances where it would make sense to |
| 32 |
remove all the certs from your certificate store and then just add your |
| 33 |
local CA's cert. In this case, the least trustworthy CA in the store is |
| 34 |
your own :) |
Archives