Nginx部署部分https与部分http

2016年12月7日10:04:32 发表评论 1,132

Nginx部署部分https与部分http

一般而言,大规模的网站都有很多台Web服务器和应用服务器组成,用户的请求可能是经由Varnish,HAProxy,Nginx之后才到应用服务器,中间有好几层。而中小规模的典型部署常见的是 Nginx+Tomcat/jboss 这种两层配置,而Tomcat或jboss 会多于一台,Nginx 作为静态文件处理和负载均衡。下面重点讲解nginx+jboss+ssl实现部分页面https部分页面http

    如果Nginx作为前端代理的话,则Tomcat/jboss不处理自己 https,全交由Nginx处理是可以的。(一般情况下nginx和Tomcat/jboss处于同一个局域网内,安全问题暂时忽略。nginx与jboss之间加密传输在本文最后说明)用户首先和Nginx建立连接,完成SSL握手,而后Nginx 作为代理以 http 协议将请求转给 tomcat 处理,Nginx再把 Tomcat/jboss 的输出通过SSL 加密发回给用户,这中间是透明的,Tomcat/jboss只是在处理 http 请求而已。因此,这种情况下不需要配置 Tomcat 的SSL,只需要配置 Nginx 的SSL 和 Proxy。

    SSL比 http 要消耗更多cpu资源(主要是在建立连接的阶段,之后还要对内容加密),所以对一般网站,只需要对部分地方采用https,大部分开放内容是没必要的,具体取决于你的业务要求。比如对于很多安全要求较低的网站,完全不用https也是可接受的。

某些页面是同时支持 http 和 https ,还是只支持 https、强制 https?

同时支持就是用户用什么协议访问都可以,那么用户的请求主要就是由页面本身的链接引导来的,因为一般用户不会自己特意去修改地址栏的。

一般我们的网站可以做成同时支持http和https,都可以访问。但是这就容易有后面说的混合内容或混合脚本的问题。

还可以规划为部分页面支持 https,一般公开页面不用https,只是将部分地方的链接改为 https 就可以了。专门期望以 https 访问的页面中,引用的绝对URL可以明确的使用 https链接。

是否强制 https ?对于安全性高的网站或网站中的部分页面,可以强制使用https访问, 即使用户在地址栏里手工把 https 改为 http, 也会被自动重定向回 https 上。比如可以通过配置web服务器 rewrite 规则将这些 http url 自动重定向到对应的 https url 上(这样维护比较简单),而不用改应用

Nginx部署部分https与部分http

解决混合内容问题(http和https)

混合内容是指:在https的页面中混合了非https的资源请求,比如图片、css、js 等等。如果是混合了非 https 的 js 代码,则被称为混合脚本。

特别注意:

(1)在http页面混有https内容时,页面排版不会发生乱排现象

(2)在https页面,只有包含以http方式引入的资源(如图片,js等)时,才算作混合内容,如果https页面有超链接(如http:www.baidu.com),但是该超链接并没有引入资源,不算做混合内容,页面显示正常,鼠标放在该超链接时,页脚显示:http://www.baidu.com或者www.baidu.com

混合内容的危害:如果只是混合了不安全的图片和css,那么受中间人攻击篡改,一般只会影响页面的显示,危害相对小一点。如果是混合了不安全的 js 代码,则这个不安全的 js 可以完全访问和修改页面中的任何内容,这是非常危险的。

所以,只有页面本身和所有引用的资源都是 https 的浏览器才认为是安全的,只要其中引用了非安全资源(即使图片),浏览器都会给出不安全的提示,特别是有 js 的情况。如果浏览器提示不安全,那样我们就达不到原来目的了。我们费了半天功夫去申请 SSL 证书,配置Web服务器,最后如果因为混合内容而前功尽弃就太糟了。

理论上,混合了第三方的内容,即使是SSL的第三方内容也不是很好。因为用户信任的是你,而不是第三方,即使第三方也支持https,但你能保证第三方就绝对安全吗。不引用任何第三方才是绝对安全的,但这样太严格了,安全其实也是一个 tradeoff 的问题,需要考虑很多方面的平衡。

Chrome出绝招阻断混合脚本漏洞:http://news.mydrivers.com/1/197/197058.htm

谷歌浏览器混合显示内容会这样指示:

谷歌浏览器混合脚本得以执行时,整个原始页面都会受到影响,原因是浏览器阻止混合内容的加载。如果Chrome的UI显示网站上存在混合内容问题,可以尝试Google的开发工具定位问题。有用的信息通常记录在JavaScript控制台(菜单->工具->JavaScript控制台),只要把提示的非https传送内容改为https传送的就可以了,这个在后面的代码中展示。

在其他主流浏览器(如IE9或FF4)需要点击确认对话框来确定是否显示混合内容。

 

Nginx+jboss+http/https详细配置

 

1、nginx.conf 中的配置示例

http {

upstream cluster{

                server 172.18.0.33:80 weight=1;

                server 172.18.0.101:8088 weight=5;

        }

upstream clusterssl{

                server 172.18.0.33:8443 weight=1;

                server 172.18.0.101:8443 weight=5;

        }

    server {

        listen       80;

        server_name  www.AAA.com;

        location / {

            proxy_pass http://cluster;

            index  index.htm;

            proxy_set_header Host $host;

            proxy_set_header X-Real-Ip $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

            proxy_connect_timeout 10;

            proxy_read_timeout 120;

        }

        location ~* /*login.htm {

            #rewrite ^(.*) https://$host$1 permanent;

            rewrite ^(.*) https://www.BBB.com$1 permanent;

        }

        location ~ \.(css|js|gif)$ {

            #rewrite ^(.*) https://$host$1 permanent;

            rewrite ^(.*) https://www.BBB.com$1 permanent;

        }

    # HTTPS server

    server {

        listen 443;

        server_name  www.BBB.com;

        ssl                  on;

        ssl_certificate      server.pem;

        ssl_certificate_key  server.key;

        ssl_session_cache    shared:SSL:10m;

        ssl_session_timeout  5m;

        ssl_protocols  SSLv3 TLSv1;

        ssl_ciphers  HIGH:!ADH:!EXPORT56:RC4+RSA:+MEDIUM;

        ssl_prefer_server_ciphers   on;

        location / {

            rewrite ^(.*) http://www.AAA.com$1 permanent;

        }

        location ~* /*login.htm {

            proxy_pass http://cluster;

            proxy_redirect off;

            proxy_set_header Host $host;

            proxy_set_header X-Real-Ip $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

        }

        location ~ \.(css|js|gif)$ {

            proxy_pass http://cluster;

            proxy_set_header Host $host;

            proxy_set_header X-Real-Ip $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

        }

    }

}

首先,用户访问http://www.AAA.com,进入网站首页,当点击登陆页面http://www.AAA.com/login.htm页面时,由于在80端口进行如下配置:

        location ~* /*login.htm {

            #rewrite ^(.*) https://$host$1 permanent;

            #当AAA与BBB相同时,可用$host常量

            rewrite ^(.*) https://www.BBB.com$1 permanent;

        }

Url重写之后,到443端口,然后通过443端口的代理配置:

        proxy_pass http://cluster;

Nginx将https请求转发给后台的jboss应用服务器。由于https状态会保持,在登陆之后跳转到其它页面时,如果不进行强制使用http,会一直保持https状态,443端口的如下配置:

    location / {

            rewrite ^(.*) http://www.AAA.com$1 permanent;

        }

会使得https状态下的非login.htm链接使用http协议。

在登录页面引入的css、js、gif等资源,由于是后端的jboss以http状态返回给nginx的,所以login.htm页面会有混合内容,浏览器认为是不安全的,不进行加载,会出现页面排版乱排等现象,谷歌浏览器提示如下:

在80端口下进行如下配置:

        location ~ \.(css|js|gif)$ {

            #rewrite ^(.*) https://$host$1 permanent;

            rewrite ^(.*) https://www.BBB.com$1 permanent;

        }

在443端口进行如下配置:

        location ~ \.(css|js|gif)$ {

            proxy_pass http://cluster;

        }

可以解决页面有混合内容的问题。

现在,另一个问题出现了,如果按照上面进行配置,那么其它非login页面的css、js、gif也都会走https,影响效率,又使得http页面存在https方式引入的内容,解决办法是把登录页面需要的资源放在一个可以区分的路径下面,location匹配的时候,让该路径下的css、js、gif等资源走https,其他路径下面的资源走http。

在代理模式下,jboss 如何识别用户的直接请求(URL、IP、https还是http )?

在透明代理下,如果不做任何配置jboss认为所有的请求都是 Nginx 发出来的,这样会导致如下的错误结果:

request.getScheme()  //总是 http,而不是实际的http或https

request.isSecure()  //总是false(因为总是http)

request.getRemoteAddr()  //总是 nginx 请求的 IP,而不是用户的IP

request.getRequestURL()  //总是 nginx 请求的URL 而不是用户实际请求的 URL

response.sendRedirect( 相对url )  //总是重定向到 http 上 (因为认为当前是 http 请求)

如果程序中把这些当实际用户请求做处理就有问题了。解决方法很简单,只需要配置一下 Nginx 就好了,而不用改程序。

配置 Nginx 的转发选项:

proxy_set_header       Host $host;

proxy_set_header  X-Real-IP  $remote_addr;

proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto  $scheme;

优化

1、优化rewrite语句:

rewrite复杂而且低效,用return语句代替,如

    rewrite  (.*)  http://www.example.org$1;

改为

    retrun 301 http://www.example.org$request_uri;

2、优化SSL配置

    SSL操作需要消耗CPU资源,所以在多处理器的系统,需要启动多个工作进程,而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手,有两种方法可以将每个客户端的握手操作数量降到最低:第一种是保持客户端长连接,在一个SSL连接发送多个请求;第二种是在并发的连接或者后续的连接中重用SSL会话参数,这样可以避免SSL握手的操作。会话缓存用于保存SSL会话,这些缓存在工作进程间共享,可以使用ssl_session_cache指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟,可以使用ssl_session_timeout加大它。下面是一个针对4核系统的配置优化的例子,使用10M的共享会话缓存:

worker_processes  4;

http {

    ssl_session_cache    shared:SSL:10m;

    ssl_session_timeout  10m;

    server {

        listen              443;

        server_name         www.example.com;

        keepalive_timeout   70;

        ssl                 on;

        ssl_certificate     www.example.com.crt;

        ssl_certificate_key www.example.com.key;

        ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;

        ssl_ciphers         HIGH:!aNULL:!MD5;

        ...

 

证书密钥的保护:

服务器证书是公开的,会被传送到每一个连接到服务器的客户端,而私钥不是公开的,不会被发送,在服务器上要保护好它,比如存放在访问受限的文件中,例如:chmod 400 ssl.key (仅root可读),当然,nginx主进程必须有读取密钥的权限;或者为私钥文件设置密码时,这样私钥虽然很安全,但是每次重启nginx服务都要输入一次密码,比较麻烦

Nginx前端机与后端jboss间部分http部分https通道实现

如果想要在nginx与jboss之间也实现加密传输,仅需要做如下关键点的修改:

(1)在jboss端配置服务器证书,并开启https端口(下面以8443端口为例)

(2)配置jboss端的部分https部分http

(2)在nginx监听443端口的服务修改如下:

        location ~* /*login.htm {

            proxy_pass https://clusterssl;

            proxy_set_header Host $host;

            proxy_set_header X-Real-Ip $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_set_header X-Forwarded-Proto $scheme;

        }

运营有道

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: