*Convergence* was a proposed strategy for replacing SSL <https://en.m.wikipedia.org/wiki/Secure_Sockets_Layer> certificate authorities <https://en.m.wikipedia.org/wiki/Certificate_authority>, first put forth by Moxie Marlinspike <https://en.m.wikipedia.org/wiki/Moxie_Marlinspike> in August 2011 while giving a talk titled "SSL and the Future of Authenticity" at the Black Hat security conference <https://en.m.wikipedia.org/wiki/Black_Hat_Briefings>. [1] <https://en.m.wikipedia.org/wiki/Convergence_%28SSL%29#cite_note-1> It was demonstrated with a Firefox addon <https://en.m.wikipedia.org/wiki/Firefox_addon> and a server-side notary daemon <https://en.m.wikipedia.org/wiki/Daemon_%28computing%29>.
https://en.m.wikipedia.org/wiki/Convergence_(SSL) On Wed, Jul 4, 2018, 5:01 PM Zenaan Harkness <[email protected]> wrote: > Snake oil to the rescue... > > > ----- Forwarded message from Zenaan Harkness <[email protected]> ----- > > From: Zenaan Harkness <[email protected]> > To: [email protected] > Date: Mon, 2 Jul 2018 11:11:13 +1000 > Subject: Re: Webmail? > > On Sun, Jul 01, 2018 at 10:40:13PM +1200, Richard Hector wrote: > > On 01/07/18 21:57, Zenaan Harkness wrote: > > >> Oh, use https:// and make sure any security is activated in conf.pl. > > > > > And with your self-issued snake oil certs, make sure you check and > > > confirm the cert on each device you want to use to access your > > > webmail server, from your home network, so that if you eventually > > > tunnel in or otherwise access it 'on the road', you have already > > > verified your own snake oil cert and a MITM should stand out like > > > unicorn balls. > > > > For any server on the internet, I don't see the point in using > > self-signed certs any more, now that letsencrypt gives you real ones for > > free. > > Only a -true- Scotsman would self sign and issue his own SSL certs :) > > I believe it's degrees of snake oil... > > > > It's a bit more of a pain for a server that's only accessed internally, > > but still doable, if you can set up a dummy site for verification (there > > are ways to do it without a web server, but I haven't needed that yet) > > It's actually a bit of an open question, but the real question is > "what level of security do you actually need or want?" … of course. > > Consider e.g.: > > - how to conduct an MITM? > - get a copy of private key, issue additional cert > - get private key, issue intermediate cert > - get intermediate cert key, issue other intermediate certs > > - is an MITM of concern to you? > - I do/don't care if the govt has open access to my certs, > and can/can't MITM my users > - I do/don't care if Random J Cracker can MITM my telecommuting > co-workers > > Most of us by now will have read at least one article about the CIA > and NSA's cornucopia of network cracking tools, bugs, physical > network bugs and "rogue" hosts hosted at every host hoster worth his > hosting salt - google, amazon, your local ISP, etc - oh, and "by > consent, possibly with $ inducement and implied threat of legal > sanction for failure to 'co-operate' with said inducement". > > But again, what level of security do you need? > > ∙ If you want minimum pain web servers accessible to the public, > providing "basic trust level", then LetsEncrypt is likely your > best approach. > > ∙ If you don't have "general public access" as a requirement, and > you are willing to double check each device accessing your local > network to ensure they've each pre-loaded your internal-only web > server cert, then your own PKI and self signed certs may give you > higher security (barring catastrophic mistakes on your part), and > certainly more control. > > In this scenario, if you don't need control over the private keys > to your electronic kingdom - by all means, use a commercial or > free provider, and LetsEncrypt is perhaps about as good as it > gets. > > For those after a higher level of certainty and control however, > there is no substitute to offline master key generation and > storage, private PKI and total in-house control over all > sub-keys/sub-certs, issuances, revocations and per-device key > signature double checking. > > If you want anything even resembling certainty that is... > > > Here's a true fist hand anecdote: > > A few years ago, I was setting up a VM and some basic web services > for a client with a top tier 'reputable' provider - one of the > largest in Australia, at least at the time. > > When connecting via ssh for the first time, the usual "This is a new > host, here's the sig, do you confirm this is the correct signature" > type message came up. > > So I check the time and it's well after peak hour (about 11pm), and > quickly dial their 24-hour tech support line, asking for someone to > please check the host signature (this was virtual hosting, just > before VMs took off), so as to preclude any superficial MITM > swankery. > > The tech says to me "Um, I'm not sure about that, I've never been > asked that question before," and promptly bumps it up to a deep tech > PoC (person of competency), who double checks the host SSH sig hash > from their internal network, confirms it's correct, then he too says > "you know, as far as I'm aware, in over 15 years, this is the first > time, ever, that any client has ever asked us to confirm their end > to end encryption/ signature!" I confirmed that he had in fact > worked at the company since it began. > > > And most important - if you intend to configure your own PKI for > "increased security" purposes, note that you really need to make sure > you use certificate pinning for your own org's certs, or disable the > other CAs "by default trusted" by your client OS browsers! - The easy > way is use a Firefox profile for your company/ internal websites/ > VPN/ telecommuters and make sure only your CA is the trusted root in > that profile! (and make sure that your internal web sites can only be > accessed from that profile) : > > Are self-signed certificates actually more secure than CA > signed certificates now? > > https://security.stackexchange.com/questions/42409/are-self-signed-certificates-actually-more-secure-than-ca-signed-certificates-no > > > > See also: > > 4 fatal problems with PKI > > https://www.csoonline.com/article/2942072/security/4-fatal-problems-with-pki.html > > SSL certificate revocation and how it is broken in practice > > https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3 > > When are self-signed certificates acceptable for businesses? > > https://www.techrepublic.com/article/when-are-self-signed-certificates-acceptable-for-businesses/ > > Good luck :) > > > ----- End forwarded message ----- >
