Matti Aarnio wrote:
On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther wrote:
On Thu, 23 Oct 2008, Ivar Lumi wrote:
After reading RFC 3207, i found probably non documented item.
For example:
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
Now if negotiation fails, whats then ?
Send error ? close connection ?
Whats the proper action ?
RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol.
So follow the rules over in the TLS specification. To quote RFC 2246:
7.2.2. Error alerts
Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of an fatal alert message, both
parties immediately close the connection. <...>
...
handshake_failure
Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error.
(Other errors may apply, depending on exactly what you mean by
"negotiation fails".)
I.e., if your end detects a fatal error, send a fatal error alert and
close the connection. If your end receives a fatal error alert, close the
connection.
So far so good, but what to do at SMTP level ?
If the error happened once TLS negotiation started, then the server has
no choice but to close the connection at SMTP level.
a) If running as "opportunistic encrypter", one can degrade the connection
to plain and try to send the message (by making a new connection and not
trying to enable TLS).
a2) Possibly sending additional informational warning to the email
originator
about the failure to run opportunistic encryption, when the message was
sent over non-encrypted connection after STARTTLS fault.
b) If the address specific routing sets a policy is to send given destination
only via encrypted and with certificate validated TLS connetion, and it
fails, then the only way is to return the message back to originator.
Most cases of using TLS and server certificates on SMTP are not getting even
certificate CN quite right. Certificate verification is purely black magic.
Yes, this could have been better documented.