Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Not that I think that’s a sane or normal thing to do.  But apparently it’s a thing people are doing.  I didn’t know about it either until I saw this twitter post and did a little research on it.

https://twitter.com/eey0re/status/951622012211900416

> On Jan 12, 2018, at 10:36 AM, Matthew D. Hardeman <mhardeman@ipifony.com> wrote:
> 
> Yes.
> 
> But there are people forwarding that to the other service port so their application only has one real listener and then that non HTTP TLS server still manages to complete the TLS-SNI challenge (via port 443).
> 
>> On Jan 12, 2018, at 10:33 AM, Gerd v. Egidy <gerd.von.egidy@intra2net.com> wrote:
>> 
>>> I did want to say that if an acceptable mechanism is found in this manner,
>>> it does help with some but not all in-band TLS validation mechanisms.  It
>>> works for web server cases.  It does not fully replace the mechanisms of
>>> the TLS-SNI sort because it would not work for other protocols running over
>>> TLS (like SMTP/TLS).  The TLS-SNI mechanisms do facilitate that.
>> 
>> Really? Isn't TLS-SNI-01/-02 just allowed over TCP port 443?
>> 
>> "This connection MUST be sent to TCP port 443 on the TLS server"
>> 
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme