Mouse wrote in <[email protected]>: |> SNI basically transmits the actual vhost you wish to visit, in URL |> terms the part between https:// and the first slash after that, [...] |> [...] |> Then, the people [...] thought it would be good to create TLSv1.3 |> [...] and decided to add SNI to that standard; not only that, but |> they *require* it to be used now. | |So, TLS 1.3 is not usable for securing anything except the Web? (That |is, if you aren't "visit"ing a "vhost"?)
For example RFC 7672[1], 8.1. "SNI Support" To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain. This precludes the use of the Secure Socket Layer (SSL) HELLO that is SSL 2.0 compatible by the SMTP client. Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records. The server MAY rely on SNI to determine which certificate chain to present to the client. Clients that don't send SNI information may not see the expected certificate chain. [1] https://tools.ietf.org/rfc/rfc7672.txt --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Lynx-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lynx-dev
