<div dir="auto"><div>I'll double check the configuration we have when I get back</div><div dir="auto">into work next year, but until then have a Merry Christmas /</div><div dir="auto">Happy holidays!</div><div dir="auto"><br></div><div dir="auto">-Terence</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, Dec 24, 2018, 13:47 Terence Honles <<a href="mailto:terence@honles.com">terence@honles.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, the regex will fail for IPv future literals, but I don't believe they are<br>
being used in practice. When they are, I'm sure the Django project will<br>
welcome the change to the RegEx.<br>
<br>
As for the configuration you proposed, we are already using that (with a 444<br>
instead of 404), but the IP literal will still pass through because it is a<br>
valid match (but an invalid hostname according to RFC 3986).<br>
<br>
-Terence<br>
<br>
On Mon, Dec 24, 2018 at 4:58 AM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank" rel="noreferrer">mdounin@mdounin.ru</a>> wrote:<br>
><br>
> Hello!<br>
><br>
> On Fri, Dec 21, 2018 at 11:59:27AM -0800, Terence Honles wrote:<br>
><br>
> > The reason I came across this code was I have NGINX handling HTTPS, and<br>
> > proxying to Django via uWSGI. Django has the following RegEx [1]_. Which is is<br>
> > compliant with the IPv6 literal notation, but causes Django to report an<br>
> > error.<br>
><br>
> Well, as far as I see the regex in question will also report an<br>
> error for perfectly valid IPvFuture literals.<br>
><br>
> > While I agree, there may not be an issue of security; Any down stream systems<br>
> > may be confused and unable to handle a malformed hostname.<br>
><br>
> If you want to prevent such names from hitting your backend<br>
> servers, a better solution might be to configure nginx to only<br>
> accept explicitly configured host names (including IP literals).<br>
> This is more or less trivial to configure and something you<br>
> probably should do anyway unless you are still supporting<br>
> pre-Host-header clients.  E.g.:<br>
><br>
> server {<br>
>     listen 80 default;<br>
>     return 404;<br>
> }<br>
><br>
> server {<br>
>     listen 80;<br>
>     server_name <a href="http://example.com" rel="noreferrer noreferrer" target="_blank">example.com</a>;<br>
>     ...<br>
> }<br>
><br>
> > Another alternative would be to rewrite the hostname to not<br>
> > include the "[" and "]" if it is not a valid IPv6 literal,<br>
><br>
> Well, this _will_ be a security issue, since it can easily result<br>
> in different processing of names in nginx and backends.<br>
><br>
> --<br>
> Maxim Dounin<br>
> <a href="http://mdounin.ru/" rel="noreferrer noreferrer" target="_blank">http://mdounin.ru/</a><br>
> _______________________________________________<br>
> nginx-devel mailing list<br>
> <a href="mailto:nginx-devel@nginx.org" target="_blank" rel="noreferrer">nginx-devel@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
><br>
</blockquote></div></div></div>