需求背景:
由于对网络安全的监督和管控越来越严格,chrome等浏览器强制要求https看样子也是大势所趋,所以我们遇到了服务http升级为https协议的需求。我们企业对外的服务早已经是https协议了,但是内部一些工具的改造还在起步阶段,本篇的改造策略只是拿jira和confluence来举个实战例子,其思想和步骤可以试用于其他场景。
http存在的漏洞和https是如何解决这些安全问题的可以详见我前面的一篇博文《https://blog.csdn.net/yejingtao703/article/details/78723276》,这里不再详细论述。
详细步骤:
1 准备证书和私钥
Openssl命令创建出key和csr,其中csr提供给认证机构换取crt证书文件,key留给自己秘密保管。
为了避免SHA-1,确保更强的安全性,我们还会采取Diffie-Hellman密钥交换。
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 2048 # 如果你的机器性能足够强大,可以用 4096 位
所生成的文件也许要妥善保管,nginx配置时会用到。
2 https转http
总体分为两大解决方案:服务端直接提供https服务和通过转换层来实现,前者我们不推荐,因为这个需要改造代码,后者也有多种实现方式,我所知的就有3种。
本地代理:Nginx
通过本地的Nginx做https解析和转发,优点是成型快,缺点是会暴露敏感信息,不方便扩展,适用于单个的web服务。
云平台LoadBalance:
直接在云平台的LoadBalance配置https监听,优点是配置简单,敏感信息权限可控且可复用,缺点是服务必须建设在云平台上。
WAF(Web公用防火墙):
本质上跟第一种方案差不多,只是把https转http这一层从本地抽走专门拿出一层来做处理,带来的优点是避免敏感信息泄露,省去了服务端配置,缺点是需要专人搭建WAF环境。
本文采用Nginx方案,这里分享下相关配置:
server {
listen 80;
server_name wiki.demo.tv;
#charset koi8-r;
#access_log logs/host.access.log main;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
if ( $args ~ decoratorName=file ){
return 403;
}
proxy_pass http://ip:port;
}
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
}
server {
listen 80;
server_name wiki.demo.tv;
rewrite ^ https://$http_host$request_uri? permanent;
server_tokens off;
}
server {
listen 443;
ssl on;
ssl_certificate /etc/nginx/ssl/demo.com.crt;
ssl_certificate_key /etc/nginx/ssl/demo.com.key;
server_name wiki.demo.tv;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:5m;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
# secure settings (A+ at SSL Labs ssltest at time of writing)
# see https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS';
ssl_prefer_server_ciphers on;
proxy_set_header X-Forwarded-For $remote_addr;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
server_tokens off;
location / {
proxy_pass http://ip:port;
proxy_set_header Host $host:443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto https;
access_log /var/log/nginx/wiki.access.log;
error_log /var/log/nginx/wiki.error.log;
proxy_read_timeout 1200s;
client_max_body_size 0;
}
}
其中80端口配置二选一,一种是强制要求https,将80转发到443;一种是https和http同时支持。
3 jira和confluence的系统配置
这个是Atlassian产品需要配置的,对于我们自己开发的web服务来说这一步是非必需的。
修改jira配置:
cd ${JIRA_HOME}/conf/server.xml
<Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>"
maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false" secure="true" scheme="https"
proxyName="jira.demo.tv" proxyPort="443"/>
修改confluence配置:
cd ${CONFLUENCE_HOME}/conf/server.xml
<Connector port="8090" connectionTimeout="20000" redirectPort="8443"
maxThreads="48" minSpareThreads="10"
enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
protocol="org.apache.coyote.http11.Http11NioProtocol"
scheme="https" secure="true" proxyName="wiki.demo.tv" proxyPort="443"/>
4 jira和confluence其他配置
1 基础路径
baseurl,由http修改为https
Jira:管理à系统à一般设置à基本URL
Confluence:管理à一般配置à站点配置à服务器主页URL
2 远程应用程序
应用程序à集成à配置应用程序链接à远程应用程序
注意事项
Iptables、防火墙放开443端口
这个是最容易被忽略的,当改为https协议后你对外服务的端口变更了,一定要保证你机器内部和所在云的安全组放通新的端口,否则将导致整个服务不可用,一次升级最终变成了一个故障。
来源:CSDN
作者:牛麦康纳
链接:https://blog.csdn.net/yejingtao703/article/details/104064285