Demand background:

Due to the increasingly strict supervision and control of network security, chrome and other browsers are forced to require https, which seems to be the general trend, so we meet the demand of upgrading the service http to https protocol. The external service of our enterprise has been https protocol for a long time, but the transformation of some internal tools is still in its infancy. The transformation strategy of this article is just to take jira and conference as an example. Its ideas and steps can be tried in other scenarios.

The vulnerabilities of http and how HTTPS solves these security problems can be seen in my previous blog, https://blog.csdn.net/yejingtao703/article/details/78723276, which will not be discussed in detail here.

Detailed steps:

1 prepare certificate and private key

The Openssl command creates a key and a csr, in which the csr is provided to the certification authority in exchange for the crt certificate file, and the key is kept in secret by itself.

In order to avoid SHA-1 and ensure stronger security, we will also adopt Diffie Hellman key exchange.

cd /etc/ssl/certs

openssl dhparam -out dhparam.pem 2048 - if your machine is powerful enough, you can use 4096 bits

The generated files may need to be kept properly, which will be used in nginx configuration.

2 https to http

There are two solutions: the server provides https service directly and implements it through the transformation layer. The former is not recommended, because it needs to change the code, and the latter has multiple implementation methods. I know three.

Local agent: Nginx

https parsing and forwarding through the local Nginx has the advantages of fast forming, and the disadvantages of exposing sensitive information and inconvenient expansion, which is suitable for a single web service.

Cloud platform LoadBalance:

Configure https monitoring directly in the LoadBalance of the cloud platform, which has the advantages of simple configuration, controllable and reusable sensitive information permissions, and the disadvantage is that the service must be built on the cloud platform.

WAF (Web public firewall):

In essence, it is similar to the first scheme. It only takes the layer of https to http out of the local area and takes one layer out for processing. The advantage is to avoid the leakage of sensitive information and to avoid the configuration of the server. The disadvantage is that special personnel are required to build the WAF environment.

In this paper, Nginx scheme is adopted, and the following configurations are shared:

  

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

One of the 80 port configurations is to force https to forward 80 to 443; the other is to support both https and http.

3 system configuration of JIRA and Conference

This is what Atlassian products need to be configured. This step is not necessary for our own web services.

To modify the jira configuration:

cd ${JIRA_HOME}/conf/server.xml

<Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
                   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"/>

Modify the 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 and conference other configurations

1 basic path

baseurl, changed from http to https

Jira: general settings basic URL of management system

Confluence: manage general configuration site configuration server homepage URL

2 remote application

Application integration configuration application link remote application

Matters needing attention

Iptables, firewall release port 443

This is the most easily ignored. When the https protocol is changed, the port of your external service is changed. Make sure that the security group inside your machine and in the cloud has new ports. Otherwise, the whole service will be unavailable, and an upgrade will eventually become a failure.