On Tue, Oct 7, 2014 at 4:28 PM, Martin Lambers <mar...@marlam.de> wrote: > On Tue, 7 Oct 2014 14:45:24 -0400, grarpamp wrote: >> On Tue, Oct 7, 2014 at 1:28 PM, Ángel González <an...@16bits.net> >> 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 ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ msmtp-users mailing list msmtp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msmtp-users
