Re: A couple of questions and concerns about Emacs network security

[Jimmy Yuen Ho Wong]

Can you preempt me with an OCSP patch, or better yet, a CT patch
already... C hurts my head and I spend more time answering emails than
writing code this week...

Stop... both of you....

P.S. If it makes you feel any better, GnuTLS does checks OCSP stapling
automatically already, and I've already submitted a patch to do CRL,
not that IGTF's CRL is particularly good...

On Sat, Jul 7, 2018 at 4:15 PM, Perry E. Metzger <address@hidden> wrote:
> On Sat, 7 Jul 2018 15:32:19 +0100 Jimmy Yuen Ho Wong
> <address@hidden> wrote:
>> I know Perry you probably want to copy what browsers do - basically
>> removing unsafe ciphers and only offer one security levels, and
>> perhaps drop support for GnuTLS version other than the most recent
>> stable version. I can tell you now that in practical terms, they
>> make very little difference. For Gmail, 85% outbound and 91%
>> inbound emails are secured with TLS[2].
>
> My main concern in the case of users reading their mail with Emacs is
> certificate forgery, and not the use of TLS itself. (The stats you
> are quoting are regardless for the use of TLS with SMTP, not with
> IMAP which is the relevant issue, and they don't tell us anything
> about the interception of mail by man-in-the-middle attacks against
> IMAP TLS connections.) Pinning (or later CT) is needed to prevent
> malefactors, including, lets be blunt, several major states, from
> using the equipment they've bought from Bluecoat and other vendors to
> intercept the TLS connections by using forged certificates. It's not a
> theoretical concern, the equipment to do this is deployed, and only
> CT and the rest will help.
>
> Downgrade attacks are also a concern of course.
>
>> For HTTP, most of the
>> checks I've implemented is already supported by a vast majority of
>> servers out there, and given that the time people spend on the web
>> vs the websites' Alexa rankings follows the Pareto distribution,
>> most of the time you won't even get a warning. No warning, no
>> decision to make.
>
> I'm also concerned about pinning or CT for things like
> mail.google.com and the like when they're accessed over HTTPS.
>
>> For the 20% of time you are not spending on Alexa top 20k, we can
>> infer from SSLLabs' SSLPulse data to get a sense of how dangerous
>> they are. SSLPulse tracks the Alexa top 150K websites, with the
>> exception of protocol downgrade defense, no other problems that I
>> check for exceed 5% on this list of servers. 5% of 20% is 1%. If
>> you only consider cipher suites independently, given that browsers
>> have removed a shit ton of unsafe cipher suites already, the chance
>> of getting an unsafe cipher suite from a handshake is very very
>> very small.
>
> The chance of getting an unsafe cipher suite in legitimate use is
> essentially zero. The chance of getting a downgrade attack is very
> very high because there are companies that sell hardware specifically
> to perform such attacks, and there's homemade equipment in deployed
> use by a number of state actors that have larger budgets and more
> custom interests.
>
>> The whole reason I'm working on fixing Emacs' network security is I
>> believe Emacs' esoteric user base is probably extreme outliers, and
>> Emacs' TLS defence is next to useless. I'm not working on this for
>> normal people here.
>
> So, I'm a security professional, partially responsible for the
> creation of some of the protocols in question, I use Emacs for
> purposes like reading email and the like, and I'm concerned that I
> want my security to be good and that the current mechanisms don't
> really give me what I need. And no, I don't want to be asked when I'm
> presented with a cert that Google specifically said isn't valid, I
> want it to be rejected so I won't accidentally say yes at 3am when
> I'm exhausted and not paying attention.
>
> Perry
> --
> Perry E. Metzger                address@hidden