support http and https on the same port

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

support http and https on the same port

Frank Liu
Stream servers can now do ssl and non-ssl on the same port:

Can this be added to http virtual hosts as well?
If ssl is on a listening port and client doesn't send ClientHello, can nginx fallback to use normal http? Maybe introduce a new directive "fallback_http on;"?

Thanks!
Frank

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Maxim Dounin
Hello!

On Wed, Jul 25, 2018 at 07:46:49AM -0700, Frank Liu wrote:

> Stream servers can now do ssl and non-ssl on the same port:
> https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/
>
> Can this be added to http virtual hosts as well?
> If ssl is on a listening port and client doesn't send ClientHello, can
> nginx fallback to use normal http? Maybe introduce a new directive
> "fallback_http on;"?

It is available since nginx 0.1.0, see the 497 error code here:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors

It might not be a good idea to actually configure things that way
though.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Frank Liu
Thanks Maxim!
Is there a way to tell nginx to treat 497 as no error, and continue normal processing?

On Wed, Jul 25, 2018 at 8:14 AM, Maxim Dounin <[hidden email]> wrote:
Hello!

On Wed, Jul 25, 2018 at 07:46:49AM -0700, Frank Liu wrote:

> Stream servers can now do ssl and non-ssl on the same port:
> https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/
>
> Can this be added to http virtual hosts as well?
> If ssl is on a listening port and client doesn't send ClientHello, can
> nginx fallback to use normal http? Maybe introduce a new directive
> "fallback_http on;"?

It is available since nginx 0.1.0, see the 497 error code here:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors

It might not be a good idea to actually configure things that way
though.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Frank Liu
I just tried it quickly. nginx gives 400 instead of 497 when I connect as http to a ssl virtual host.

server {
  listen       8443 ssl;
  server_name  localhost;

  ssl_certificate      /opt/nginx/ssl/localhost.crt;
  ssl_certificate_key  /opt/nginx/ssl/localhost.key;

  ssl_session_cache    shared:SSL:10m;
  ssl_session_timeout  10m;

}

curl -v http://localhost:8443
* About to connect() to localhost port 8443 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8443 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8443
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: nginx/1.15.2
< Date: Wed, 25 Jul 2018 17:23:24 GMT
< Content-Type: text/html
< Content-Length: 271
< Connection: close
<
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.15.2</center>
</body>
</html>
* Closing connection 0

Am I missing something?


On Wed, Jul 25, 2018 at 9:16 AM, Frank Liu <[hidden email]> wrote:
Thanks Maxim!
Is there a way to tell nginx to treat 497 as no error, and continue normal processing?

On Wed, Jul 25, 2018 at 8:14 AM, Maxim Dounin <[hidden email]> wrote:
Hello!

On Wed, Jul 25, 2018 at 07:46:49AM -0700, Frank Liu wrote:

> Stream servers can now do ssl and non-ssl on the same port:
> https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/
>
> Can this be added to http virtual hosts as well?
> If ssl is on a listening port and client doesn't send ClientHello, can
> nginx fallback to use normal http? Maybe introduce a new directive
> "fallback_http on;"?

It is available since nginx 0.1.0, see the 497 error code here:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors

It might not be a good idea to actually configure things that way
though.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx



_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Frank Liu
I tried:

error_page 497 $request_uri;

It is kind of working, and I get the correct content/code back, but the response header is still has 400:

HTTP/1.1 400 Bad Request

My use case has nginx as a reverse proxy, and the real response code from upstream is dropped though the response body and other headers are retained.

I also tried:
error_page 497 =200 $request_uri;
and now I get:
HTTP/1.1 200 OK
instead of real response code from upstream.








On Wed, Jul 25, 2018 at 10:26 AM, Frank Liu <[hidden email]> wrote:
I just tried it quickly. nginx gives 400 instead of 497 when I connect as http to a ssl virtual host.

server {
  listen       8443 ssl;
  server_name  localhost;

  ssl_certificate      /opt/nginx/ssl/localhost.crt;
  ssl_certificate_key  /opt/nginx/ssl/localhost.key;

  ssl_session_cache    shared:SSL:10m;
  ssl_session_timeout  10m;

}

curl -v http://localhost:8443
* About to connect() to localhost port 8443 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8443 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8443
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: nginx/1.15.2
< Date: Wed, 25 Jul 2018 17:23:24 GMT
< Content-Type: text/html
< Content-Length: 271
< Connection: close
<
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.15.2</center>
</body>
</html>
* Closing connection 0

Am I missing something?


On Wed, Jul 25, 2018 at 9:16 AM, Frank Liu <[hidden email]> wrote:
Thanks Maxim!
Is there a way to tell nginx to treat 497 as no error, and continue normal processing?

On Wed, Jul 25, 2018 at 8:14 AM, Maxim Dounin <[hidden email]> wrote:
Hello!

On Wed, Jul 25, 2018 at 07:46:49AM -0700, Frank Liu wrote:

> Stream servers can now do ssl and non-ssl on the same port:
> https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-2/
>
> Can this be added to http virtual hosts as well?
> If ssl is on a listening port and client doesn't send ClientHello, can
> nginx fallback to use normal http? Maybe introduce a new directive
> "fallback_http on;"?

It is available since nginx 0.1.0, see the 497 error code here:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors

It might not be a good idea to actually configure things that way
though.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx




_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Maxim Dounin
Hello!

On Wed, Jul 25, 2018 at 11:37:20AM -0700, Frank Liu wrote:

> I tried:
>
> error_page 497 $request_uri;
>
> It is kind of working, and I get the correct content/code back, but the
> response header is still has 400:
>
> HTTP/1.1 400 Bad Request
>
> My use case has nginx as a reverse proxy, and the real response code from
> upstream is dropped though the response body and other headers are retained.
>
> I also tried:
> error_page 497 =200 $request_uri;
> and now I get:
> HTTP/1.1 200 OK
> instead of real response code from upstream.

Try this instead:

    error_page 497 = @http;

    location @http {
        proxy_pass http://upstream.server;
    }

But, as previously said, it might not be a good idea to actually
configure things that way.  Rather, 497 can and should be used to
return a proper error and/or redirection to the correct address
with the protocol properly specified.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: support http and https on the same port

Frank Liu
In the current setup, I have
 location / {
   ...
   bunch of stuff
   ...
   proxy_pass http://upstream.server;
  }

Instead of duplicating the whole location block, can we do something like
 location @http | / {
   ...
   bunch of stuff
   ...
   proxy_pass http://upstream.server;

 }


On Wed, Jul 25, 2018 at 1:23 PM, Maxim Dounin <[hidden email]> wrote:
Hello!

On Wed, Jul 25, 2018 at 11:37:20AM -0700, Frank Liu wrote:

> I tried:
>
> error_page 497 $request_uri;
>
> It is kind of working, and I get the correct content/code back, but the
> response header is still has 400:
>
> HTTP/1.1 400 Bad Request
>
> My use case has nginx as a reverse proxy, and the real response code from
> upstream is dropped though the response body and other headers are retained.
>
> I also tried:
> error_page 497 =200 $request_uri;
> and now I get:
> HTTP/1.1 200 OK
> instead of real response code from upstream.

Try this instead:

    error_page 497 = @http;

    location @http {
        proxy_pass http://upstream.server;
    }

But, as previously said, it might not be a good idea to actually
configure things that way.  Rather, 497 can and should be used to
return a proper error and/or redirection to the correct address
with the protocol properly specified.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx