You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per Brian's suggestion, splitting this off of PR #105.
SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible."
Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
The text was updated successfully, but these errors were encountered:
Per Brian's suggestion, splitting this off of PR #105.
SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible."
Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
The text was updated successfully, but these errors were encountered: