Snake oil to the rescue... ----- Forwarded message from Zenaan Harkness <zenaan@freedbms.net> ----- From: Zenaan Harkness <zenaan@freedbms.net> To: debian-user@lists.debian.org 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-certifica... See also: 4 fatal problems with PKI https://www.csoonline.com/article/2942072/security/4-fatal-problems-with-pki... SSL certificate revocation and how it is broken in practice https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken... When are self-signed certificates acceptable for businesses? https://www.techrepublic.com/article/when-are-self-signed-certificates-accep... Good luck :) ----- End forwarded message -----
*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 <zen@freedbms.net> wrote:
Snake oil to the rescue...
----- Forwarded message from Zenaan Harkness <zenaan@freedbms.net> -----
From: Zenaan Harkness <zenaan@freedbms.net> To: debian-user@lists.debian.org 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-certifica...
See also:
4 fatal problems with PKI
https://www.csoonline.com/article/2942072/security/4-fatal-problems-with-pki...
SSL certificate revocation and how it is broken in practice
https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken...
When are self-signed certificates acceptable for businesses?
https://www.techrepublic.com/article/when-are-self-signed-certificates-accep...
Good luck :)
----- End forwarded message -----
participants (2)
-
Steven Schear
-
Zenaan Harkness