Loading ...
Sorry, an error occurred while loading the content.

301306Re: Individual smtpd_tls_ask_ccert?

Expand Messages
  • BlueStar88
    Jul 29, 2014
      Am 29.07.2014 um 19:06 schrieb Viktor Dukhovni:
      > The syntactic overhead can be reduced, by making "lookup_client_helo_name"
      > implicit:
      > smtpd_tls_ccert_policy = static:dane
      > and we could also make "static:" implicit when the string is one
      > of: "no | ask | require | dane". Thus enabling a no-overhead form:
      > smtpd_tls_ccert_policy = ask
      > In addition we could also support "dane-only" (requiring TLSA RRs
      > from a particular set of clients), and even allow the table lookups
      > to return a certificate or public key fingerprint rather than "require".
      > Which brings us back to the key question, what is the real motivation
      > for this? Preventing HELO forgery? Making TLS access control easier
      > to use (with "dane-only", one might be able to use check_helo_access
      > safely, because certain HELO names would be authenticated)? Some sort
      > of audit-trail that the client connection was not MiTMed?
      > What are we really gaining here? Note that active attackers on the
      > network path can change any of the three inputs (client IP, client
      > name or client HELO name), so unless the client is using an MiTM
      > resistant sending policy, we can't prevent MiTM attacks, rather
      > we can only detect their absense in some cases and perhaps grant
      > the client greater access.

      First we should extend DNS using another MX-like entry, to be able to
      define authoritative MTA client nodes for a specific domain, so we have
      something to stick on. Then we can build the same ("backfiring")
      security checks, like we have on server connections today.

      Wishful thinking...


    • Show all 25 messages in this topic