Re: [msmtp-users] Proxy support patch

[grarpamp <grarpamp@...20...>]

On Tue, Oct 7, 2014 at 4:28 PM, Martin Lambers <marlam@...23...> wrote:
> On Tue, 7 Oct 2014 14:45:24 -0400, grarpamp wrote:
>> On Tue, Oct 7, 2014 at 1:28 PM, Ángel González <angel@...375....>
>> wrote:
>> > CustaiCo wrote:
>> >> Because of how cleanly seperated the network code is from the rest
>> >> of the application, I'm fairly sure that there should be no leaks,
>> >> unless the ssl library decides to open it's own connections for no
>> >> reason.
>> >
>> > Like doing an OCSP check?
>> >
>> > (although neither openssl nor gnutls seem to do that automatically
>> > nowadays)
>>
>> Exactly like that, it's worth looking for, ie: can the user's TLS
>> config or TLS compile default turn on OCSP

I meant TLS regarding in the openssl/gnutls compile/config as to
any OCSP capabilities therein that would be available, or gotchas,
to an app (msmtp) including those TLS runtime libs.

> Currently you can use --tls-crl-file, and you have to update the CRL
> file via some external mechanism. Though I doubt that anybody does
> that.

OCSP is really for real time lookups, otherwise the user will
always be behind risk of their own audit timeframe. So unless
'msmtp --ocsp' were to enable an on the fly cert checking option
in the included TLS runtime lib, 'msmtp --tls-crl-file' would be moot.
If user is trying to blackball certs in --tls-crl-file, they'd be better
off just pinning msmtp tls_fingerprint option in that moot case.
(Well, unless they are trying to say do not accept those in tls-crl-file
but accept the rest of the universe full of [risky] certs. In this case if they
were trying to accept a cluster of servers that do not use a single
CN=wildcarded server cert, it would be better to allow multiple tls_fingerprint
statements per server name. I think we talked about that a while back.
Or maybe it was fetchmail, same difference as far as cert handling goes :-)

(BTW, I think msmtp and fetchmail generally have the more advanced
knowledge, options and care for TLS/certs/fingerprint stuff of any
competing cli apps so far. Thanks!)

> Note that if you want automatic revocation checking via OCSP, you have
> to be very careful not to reveal information about which servers you
> contact at which time. (As far as I know, the certificate you want to
> check is sent to the server. And OCSP may not even use encryption
> itself, so all information you reveal is public.)

Presumably, if user is using clearnet path for smtp they don't care
much about additionally telling the given server in cert, or user's
own specified OCSP server. what smtp service they're contacting.

And if they're using Tor or I2P or whatever, they probably don't
care either because their transport to the server is anonymized
anyways. So long as all of the following end up going
through the socks5 server they specified in msmtp config:
- DNS request for smtp server IP/onion/i2p
- TCP to smtp server
- DNS request for OCSP server IP/onion/i2p
- TCP to OCSP server

The last two are what would need to be further caught
for socks5, or somehow pushed down as socks5 config
into the TLS runtime library msmtp uses, for when the
TLS lib does OCSP lookup.


Some docs...
http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
http://tools.ietf.org/html/rfc6960  # OCSP
 (cert metadata is sent, may use TLS on wire)
http://en.wikipedia.org/wiki/Revocation_list
http://tools.ietf.org/html/rfc5280  # CRL