On Fri, 11 Jul 2014 14:44:42 +0000 Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
>On Fri, Jul 11, 2014 at 11:10:37AM +0200, BlueStar88 wrote: > >> Postfix in fact does already host-certificate checks in both >> directions/roles, which results in "Trusted TLS connections >> established from/to ..." in the optimum case. > >What would the server do differently with a client certificate than >without? You want access control based on a client name? Which >name? (Certificates can have many subjectAlternativeName values). I think it's a server certificate rather than a client certificate, which the server gets presented. If we talk about certificate types, not connection roles. I use smtpd_tls_ask_ccert = yes smtpd_tls_loglevel = 2 for quite some while. I can see successful chain walks on inbound connections resulting in "Trusted TLS connection established from". I think the server checks, if the peer hostname fits the CN. Example: --- Jul 11 10:32:49 mail postfix/smtpd[10007]: connect from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jul 11 10:32:49 mail postfix/smtpd[10007]: setting up TLS connection from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jul 11 10:32:49 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLS cipher list "AESGCM:AES:RC4:!MD5:!aNULL" Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:before/accept initialization Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 read client hello A Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write server hello A Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write certificate A Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write key exchange A Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write certificate request A Jul 11 10:32:49 mail postfix/smtpd[10007]: SSL_accept:SSLv3 flush data Jul 11 10:32:50 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: certificate verification depth=2 verify=1 subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA Jul 11 10:32:50 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: certificate verification depth=1 verify=1 subject=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA Jul 11 10:32:50 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: certificate verification depth=0 verify=1 subject=/serialNumber=N0-e9VU8hY-1kQU0pYRxXbnJnkVmdCJx/OU=1307249850/OU=See www.geotrust.com/resources/cps (c)14/OU=Domain Control Validated - QuickSSL(R)/CN=mail.cloud9.net Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 read client certificate A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 read client key exchange A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 read certificate verify A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 read finished A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write change cipher spec A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 write finished A Jul 11 10:32:50 mail postfix/smtpd[10007]: SSL_accept:SSLv3 flush data Jul 11 10:32:50 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: save session E2F6193AAE4EED2A64C30DB635C4CD554E9A5C5E27C4951E39D1B48B5EDAB9C1&s=smtp&l=268439567 to smtpd cache Jul 11 10:32:50 mail postfix/tlsmgr[30527]: put smtpd session id=E2F6193AAE4EED2A64C30DB635C4CD554E9A5C5E27C4951E39D1B48B5EDAB9C1&s=smtp&l=268439567 [data 1485 bytes] Jul 11 10:32:50 mail postfix/tlsmgr[30527]: write smtpd TLS cache entry E2F6193AAE4EED2A64C30DB635C4CD554E9A5C5E27C4951E39D1B48B5EDAB9C1&s=smtp&l=268439567: time=1405074770 [data 1485 bytes] Jul 11 10:32:50 mail postfix/smtpd[10007]: subject=/serialNumber=N0-e9VU8hY-1kQU0pYRxXbnJnkVmdCJx/OU=1307249850/OU=See www.geotrust.com/resources/cps (c)14/OU=Domain Control Validated - QuickSSL(R)/CN=mail.cloud9.net Jul 11 10:32:50 mail postfix/smtpd[10007]: issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA Jul 11 10:32:50 mail postfix/smtpd[10007]: russian-caravan.cloud9.net[2604:8d00:0:1::4]: subject_CN=mail.cloud9.net, issuer=GeoTrust DV SSL CA, fingerprint=B1:10:46:EB:3A:16:C1:ED:2C:69:83:53:5C:0D:A3:AA:E7:55:19:6F, pkey_fingerprint=36:2D:38:B7:FF:38:B0:51:63:0A:4B:89:D3:D5:D6:5E:D1:36:42:93 Jul 11 10:32:50 mail postfix/smtpd[10007]: Trusted TLS connection established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Jul 11 10:32:50 mail postfix/smtpd[10007]: C648340F97: client=russian-caravan.cloud9.net[2604:8d00:0:1::4] Jul 11 10:32:50 mail postfix/cleanup[10796]: C648340F97: message-id=<20140711123111.0f6e0738@ultrabook1> Jul 11 10:32:50 mail postfix/qmgr[22705]: C648340F97: from=<owner-postfix-us...@postfix.org>, size=4064, nrcpt=1 (queue active) Jul 11 10:32:51 mail postfix/smtpd[10007]: disconnect from russian-caravan.cloud9.net[2604:8d00:0:1::4] Jul 11 10:32:50 mail postfix/smtpd[10007]: Trusted TLS connection established from russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) --- This was an inbound connection from the majordomo host of this mailing list. You can see a successful chain walk. The point I'm trying to make is now self explainable: I like to make a useful use of this positive (or negative) result in the same way, it is possible on outbound connections (-> verify/secure/fingerprint). >> Inbound-wise (smtpd) I'm able to set "none", "may" and "encrypt" >> as "smtpd_tls_security_level". > >The server has no secure reference identity for the client, and thus >cannot perform PKIX name checks. Therefore "secure", "verify" and >"dane" are not applicable. The "check_cccert_access" feature can >do access control based on client certificate fingerprints. We're talking about MTA to MTA connections, not MUA to MTA ones. So there are references (FQDN/rDNS) against CN and certificates names extension. They are the same ones like talking outbound to other MTAs. Well, it just works as expected, if you see the result in the example above. >> What exactly is the point on having a complete certificate check >> on inbound connections and being not able to make any use of it? > >Not much, I generally recommend an empty CA list. However, you >can use CAs with: > > http://www.postfix.org/postconf.5.html#smtpd_tls_req_ccert > http://www.postfix.org/postconf.5.html#permit_tls_all_clientcerts > >> Many large email providers and commercial organisations have a >> provable host certificate in their MTA's client-role in place, just >> waiting to make a strict use of, if someone likes to. > >SMTP is not like HTTPS, and CA issued certificates are of little >use in SMTP: Well, you have a trustable host verification (let the trust pain against CA aside). It's the same outcome, like on HTTPS connections. >http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10#section-1.3 As already said: The benefit of DANE is cool, but as for now it works only for outbound connections, even it must not. I would like to check the inbound connection too, by comparing the given hash to the TLSA statement. If the remote server shows a certificate after I've asked for it, why shouldn't be able to use the same measures of verification (chainwalk, DANE), like on outbound server connections? >What concretely would you do? Wishful thinking is all well and good, >but reality means that a design has to work and deliver some benefits >to justify its costs. I think I already made my point. The above example states, that the current Postfix instance was aware of the correct integrity of the inbound server connection from the other MTA server (thus "Trusted TLS connection established from russian-caravan.cloud9.net"). But there's simply no way to tell the server to drop/reject connections, when there is another result like "Anonymous TLS connection established from...". This is stupid, because it simply works the other way around (outbound), where additional security levels make use of the actual chain walk or fingerprint comparison result. The benefit would be, to be able to make a clear statement about the security level reached in both directions (MTA -> MTA and MTA <- MTA) without depending on the unknown remote peers settings (secure/verify/fp/may/whatever) and to take appropriate actions (accept/reject). >You can use check_ccert_access, provided you're provisioning the >keys on both ends. No, I'm talking about several dozens (around 20% of my peers) of already existing public MTA servers (Google, for example), which already provide checkable host based CA certificates on their outbound connections on request by the target MTA (-> "smtpd_tls_ask_ccert = yes"). There's no broad use of it, I guess, but that means nothing to me. ;-) I simply wish to consequently drop/reject inbound connections from MTAs (servers not clients!), which were not checked successfully against their CA or my stored fingerprint. Regards BlueStar88
signature.asc
Description: PGP signature
