Nginx部署部分https与部分http

http://blog.csdn.net/na_tion/article/details/17334669

 

 一般而言，大规模的网站都有很多台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 上（这样维护比较简单），而不用改应用

 

 

解决混合内容问题(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页面会有混合内容，浏览器认为是不安全的，不进行加载，会出现页面排版乱排等现象，谷歌浏览器提示如下：

 

打开谷歌浏览器:菜单->工具->JavaScript控制台，信息如下

 

 

IE9显示如下：

 

 

 

在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;

        }

(3)修改其它混合内容