disable TLS negotiation for remotes that fail STARTTLS

[msimerson]

the idea

If a remote attempts to connect and fails, cache their IP in an in-memory no-tls object. The next time that IP connects:

• don't offer STARTTLS
• remove their IP from the no-tls object

This would:

• permit mail to make it though from MTAs and MUAs with old/broken SSL/TLS implementations
• permit Haraka to require more secure TLS settings with less impact
• automatically enable TLS when those hosts fix/upgrade their TLS

[jaredj]

+1, if someone not currently using Haraka can comment on this as a general MTA proposal :)

[jaredj]

+1, if someone not currently using Haraka can comment on this as a general MTA proposal :)

[baudehlo]

Concern: There may be an attack vector whereby a client could be forced to downgrade to plaintext when they never have before. Some sort of protection against that would be useful.

note: MITM makes it already possible to perform this attack, so it would have to be a non-MITM attack vector to be relevant or worse than the current situation.

[baudehlo]

Concern: There may be an attack vector whereby a client could be forced to downgrade to plaintext when they never have before. Some sort of protection against that would be useful.

note: MITM makes it already possible to perform this attack, so it would have to be a non-MITM attack vector to be relevant or worse than the current situation.

[msimerson]

@msimerson said:

TLS should also have a "require" list as well
such as gmail.com
maybe even "learn" that list automatically, and refuse to connect to remotes
that used to offer STAARTTLS but currently don't

@godsflaw: that is a very good idea given recent downgrade attacks

[msimerson]

@msimerson said:

TLS should also have a "require" list as well
such as gmail.com
maybe even "learn" that list automatically, and refuse to connect to remotes
that used to offer STAARTTLS but currently don't

@godsflaw: that is a very good idea given recent downgrade attacks

[jaredj]

If I'm not mistaken, the original proposal plus the dynamic 'require' list would mean that if two haraka servers were talking to each other and TLS broke:

• on the first attempt, the sending haraka server would note that the receiving haraka server offered STARTTLS
• when TLS broke on the first attempt, the receiving haraka server would note that it failed and add the sending server to the no-tls object
• on the second attempt, the receiving server would not offer STARTTLS; the sending server would refuse to talk to the receiving server because it was no longer offering STARTTLS.

Just sayin'

[jaredj]

If I'm not mistaken, the original proposal plus the dynamic 'require' list would mean that if two haraka servers were talking to each other and TLS broke:

• on the first attempt, the sending haraka server would note that the receiving haraka server offered STARTTLS
• when TLS broke on the first attempt, the receiving haraka server would note that it failed and add the sending server to the no-tls object
• on the second attempt, the receiving server would not offer STARTTLS; the sending server would refuse to talk to the receiving server because it was no longer offering STARTTLS.

Just sayin'

[msimerson]

@jaredj absolutely true. However, that's exactly 0% worse than today, when a failed STARTTLS means email doesn't get delivered (until a human gets involved). With a "don't regress" option, the benefit is rejecting that extremely remote possibility of a MITM attack. I don't think that feature should be enabled by default, but I still think it's a great feature. The tin-foil hat crowd would also approve.

[tls]
; cache list of remotes that successfully STARTTLS with us. Require them to use TLS in the future.
remember_hosts=false

; remember hosts with valid signed certs. Require future connections from these hosts
; to have valid certificates.
remember_trusted_hosts=false

; remember when a host attempts STARTTLS and fails. The next time they connect, don't
; offer STARTTLS option (so message gets delivered). This trades a little bit of security for
; more reliably mail delivery.
disable_for_failed_hosts=true

[msimerson]

@jaredj absolutely true. However, that's exactly 0% worse than today, when a failed STARTTLS means email doesn't get delivered (until a human gets involved). With a "don't regress" option, the benefit is rejecting that extremely remote possibility of a MITM attack. I don't think that feature should be enabled by default, but I still think it's a great feature. The tin-foil hat crowd would also approve.

[tls]
; cache list of remotes that successfully STARTTLS with us. Require them to use TLS in the future.
remember_hosts=false

; remember hosts with valid signed certs. Require future connections from these hosts
; to have valid certificates.
remember_trusted_hosts=false

; remember when a host attempts STARTTLS and fails. The next time they connect, don't
; offer STARTTLS option (so message gets delivered). This trades a little bit of security for
; more reliably mail delivery.
disable_for_failed_hosts=true