Sunday, August 26, 2018

Chrome browser always redirects http to https

When I access some website, it always redirects the URL from http to https even I manually enter I wonder how it happens so dig it a bit further and find out Chrome always does a 307 Internal Redirect

How to stop an automatic redirect from “http://” to “https://” in Chrome?
To answer this question, we need understand why Chrome behaves in this way. specifies HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header (Strict-Transport-Security). Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

For example:

Strict-Transport-Security: max-age=31536000; includeSubDomain

The main benefits HSTS can bring in terms of security:
  1. HSTS automatically redirects HTTP requests to HTTPS for the target domain
  2. HSTS does not allow a user to override the invalid certificate message
Here are solutions to stop HSTS:
1) Server side: Disable on web server side, for instance, on Nginx, set max-age to zero
add_header Strict-Transport-Security "max-age=0;";

2) Client side: Delete domain security policies from browser side, for instance, go to chrome://net-internals/#hsts and delete the target domain. However, you cannot delete browser preloaded entries


vi comment and uncomment multiple lines

Comment multiple lines
  1. Press ESC
  2. Go to the starting line, press ctrl+v to enable visual block mode
  3. Use down arrow or k key to select multiple lines
  4. Press shift+I to enable insert mode
  5. Press # to add comment to first line, then press ESC, then wait for 1 second to get # added to all lines
Another option is:
  1. Press ESC
  2. Go to the starting line, press ctrl+v to enable visual block mode
  3. Use down arrow or k key to select multiple lines
  4. Press shift+ : to do search and replace ('<,'> will be automatically added)
  5. Type  s/^/#/ to add # to comment out selected lines
Uncomment multiple lines
  1. Press ctrl+v to enable visual block mode
  2. Move down to select lines
  3. Press x to uncomment selected lines

Thursday, August 23, 2018

UCaaS security framework

Cloud UCaaS (Unified Communications as a Service) needs a security framework to make it secure and reliable in the cloud for Meetings, Phone and Chat.

1) Secure data center
UCaaS provider (vendor) needs facilities with strong physical protections, redundant power, and tested disaster recovery procedures.

2) Robust network security
UCaaS vendor must add unique protections designed to prevent attacks on the infrastructure, preventing service disruption, data breaches, fraud, and service high-jacking. Also needs to resolve firewall traversal problems in VoIP systems with network address translation (NAT) support for static IP configuration and “Keep-Alive” SIP signaling.

3) Secure voice
All voice traffic within cloud phone system should be encrypted to prevent eavesdropping on voice calls.  Provide additional security for IP phone calls using SIP over TLS and SRTP encryption.

4) Data encryption
All data should be encrypted in transit and at rest, with audit-able record-keeping and reporting. It includes everything from physical protections at data centers to encrypted storage to comprehensive digital tracking with clear audit trails.

5) Fraud prevention
The service provider should have protections built in to the service layer and should conduct continuous monitoring for dangerous anomalies or other indicators of toll fraud and service abuse.

6) User access controls
To ensure only authorized users access cloud communications accounts and services, the vendor should implement at a minimum strong password policies and ideally two-factor authentication as well as single sign-on (SSO).

7) Account management and administration
Administrators can instantly revoke the remote user’s access to the cloud network—and thereby to customer contacts, CRM info, and other corporate information—and almost no data resides on the device itself.

Hunt Group vs Call Queue

Hunt group and call queue have the same purpose to distribute incoming calls. They are very similar. The key difference is queue. However, call queue has more complexity,  better customization, better management and better distribution, and is more expensive.

In telephony, Hunt group (a.k.a. ring group, call group, line hunting) is the method of distributing phone calls from a single telephone number to a group of phone lines. Specifically, it refers to the process or algorithm used to select which line will receive the call. Hunt groups are supported by most PBX phone systems.

A hunt group is an extension or phone number that rings directly to multiple phones defined in the Hunt Group. Calls can be delivered in several different manners. They can be sent sequentially, (i.e. if nobody answers it goes to the next line in the group), or simultaneously, (i.e. all the phones ring and the first to answer takes the call). Other options include, round robin, percentage weighting, least used line etc.

When a call comes into a ring group, it rings the phones in the group as per the setup. But if a phone is busy then that phone is temporary out of the group. When all phones in the group are busy then the ring group will no longer "hold" the calls and will follow the call handling rules set up in the hunt group for when the phones are busy/not answered. Usually the call is forwarded to voicemail or gets disconnected.

When a call comes into a call queue, it will keep the caller in the queue even if ALL phones in the queue are busy. The queue will only move on when the queue timeout is reached or there are no extensions logged in.

Call Queue is a concept used in inbound call centers. Call centers use an Automatic Call Distributor (ACD) to distribute incoming calls to specific resources (agents) in the center. ACD holds queued calls in First In, First Out order until agents become available. Administrator can monitor call queue status and make dynamic adjustment to the queue based on incoming call volume.

Usually there are 4 Types of Call Queues

1. Round-robin (longest idle) – routes callers to the available agent that has been idle longest.
2. Ring All –  routes callers to all available agents at the same time.
3. Linear Hunt – routes callers to the available agents in a predefined order. The order is defined when editing the queue's agents.
4. Linear Cascade – routes callers to groups of available agents in a predefined order. The order is defined when editing the queue's agents.

To sum up, if you want to keep your callers in the queue while you finish your other calls then use a queue. If you want them to go to voicemail then use a hunt group.

Wednesday, August 22, 2018

RingCentral Phone provisioning is unsecure

Recently I provisioned a Cisco SPA-525G2 Desk Phone to my RingCentral Free Trial account, and found their provisioning process is totally not secure.

When I added an existing phone on account admin portal, it prompted me to input the IP address of my IP Desk Phone. I am curious how the flow works underneath, then I dig it out and find RingCentral uses http instead of https. It doesn't provide either server side certificate or client side certificate for mutual TLS authentication. This means the provisioning data packets are exposed to hackers, and also any device can get provisioned through their provisioning portal. I am very surprised of their design from security perspective.

Phone resync URL$SN&pn=$PN

Proxy to their provisioning portal using HTTP$SN&pn=$PN

Variables in the URL will be replaced by desk Phone with serial number and product model

If you sniff the network, you can clearly see the request and response in clear text (including user ID, password, auth ID etc info in plain XML file), and you can use any User agent to do the provisioning acting as a Cisco IP Phone.

This design worries me about their security design. I am not sure if they design by purpose or design by mistake.

Thursday, August 16, 2018

Mutual TLS Authentication

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer. TLS also offers client-to-server authentication using client-side X.509 authentication.

When Mutual TLS authentication is in place, both client and server authenticate each other through the digital certificate so that both parties are assured of the others' identity. In this aspect, both client and server use 12 handshake messages to establish the encrypted channel prior to message exchanging.

Refer to

When set up Mutual TLS authentication, it involves creating your own Certification Authority, self-signing the server certificate and client certificate, then installs self-signed certificate on server and client. The detailed steps are as followings:

1. Generate CA certificate:
1.1. Generate CA key:
openssl genrsa -out ca.key 2048
1.2. Generate CA certificate request:
openssl req -new -key ca.key -out ca.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/CN=Root/
1.3. Generate CA certificate:
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.pem

2. Generate server certificate:
2.1. Generate server key:
openssl genrsa -out server.key 2048
2.2. Generate certificate request:
openssl req -new -key server.key -out server.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/
2.3. Generate certificate:
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out -days

3. Generate client certificate:
3.1. Generate client key:
openssl genrsa -out client.key 2048
3.2. Generate certificate request:
openssl req -new -key client.key -out client.csr -subj /C=CN/ST=FJ/L=City/O="Company"/OU=Dept/CN=ClientID/
3.3. Generate certificate:
openssl x509 -req -in client.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out client.pem -days 365

4. Combine cert and key:
cat client.pem client.key > client2.pem

Some client like Firefox, to install the client certificate, we’ll need a PKCS#12 file which stores both the certificate and the client’s private key.
openssl pkcs12 -export -clcerts -in client.pem -inkey client.key -out client2.p12

5. Configure server:
TLSCACertificateFile ca.pem
TLSCertificateKeyFile server.key
TLSVerifyClient demand

ssl_certificate_key server.key;
ssl_client_certificate ca.pem;
ssl_verify_client on;

6. Configure client (device or browser):
6.1 Add ca.pem as a trusted CA certificate on client side
6.2 Add client2.pem or client2.p12 as a client certificate and use it also gives step-by-step instructions to set up mutual authentication using openssl commands.

CA certificate
openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key
openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt
chmod 444 ca/ca.crt
openssl x509 -noout -text -in ca/ca.crt

Server certificate
openssl genrsa -out server/ 2048
chmod 400 server/
openssl req -new -key server/ -sha256 -out server/
openssl x509 -req -days 365 -sha256 -in server/ -CA ca/ca.crt -CAkey ca/ca.key -set_serial 1 -out server/
chmod 444 server/
openssl x509 -noout -text -in server/
openssl verify -CAfile ca/ca.crt server/

Client certificate
openssl genrsa -out client/heiko.key 2048
openssl req -new -key client/heiko.key -out client/heiko.csr
openssl x509 -req -days 365 -sha256 -in client/heiko.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt
openssl pkcs12 -export -clcerts -in client/heiko.crt -inkey client/heiko.key -out client/heiko.p12

Nginx server config
ssl_certificate /etc/nginx/certs/server/;
ssl_certificate_key /etc/nginx/certs/server/;
ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
ssl_verify_client on;

Friday, August 10, 2018

Server Name Indication (SNI)

SNI (Server Name Indication) is an extension for SSL/TLS protocol. This extension allows the client to recognize the connecting hostname during the handshake process.  SNI permits a server to use different SSL certificates over the same IP address. Therefore, it serves correct certificates for those websites and delivers secured site to the customer. Each certificate is bind with particular FQDN, and with the help of SNI, the server picks the right certificate for the particular domain name.

A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.

During ssl handshake "Client Hello" packet, you should see "Extension: server_name".

Latest Nignx server supports SNI. If you type: nginx -V
You should see: TLS SNI support enabled

Wednesday, August 8, 2018

SSL certificate types

Speaking of SSL certificate types, usually we have two dimensions to categorize.

From validation dimension, there are three types of SSL certificate available today:
  1. Extended Validation (EV SSL)
  2. Organization Validated (OV SSL) 
  3. Domain Validated (DV SSL)
From domain name dimension, there are also three types of SSL certificate available today:
  1. Single-name (valid for only single domain)
  2. wildcard (valid for all subdomains)
  3. multi-name (valid for multiple domains/subdomains, called SAN or UC certificate)
You can have a wildcard cert * which is valid for all subdomains.
You can have a single-name cert which is only valid for this host
You can have a multi-name cert,, this is called a SAN (Subject Alternative Name) Certificate. They are often called "UC-Certificate" as well.

For example:

When Wildcard SSL certificate is issued for *, you can secure your unlimited number of sub domains over the main domain.

If the Wildcard SSL certificate is issued on *, in that case you can secure all second level subdomains which are listed under the

If you want to secure limited number of different domains and second level domains, then you can choose multi domain SSL that can secure up to 100 domain names with a single certificate.


You may be wondering what the technical difference is between these types. It all comes down to the Subject Alternative Name (SAN) field that is embedded in the certificate when it’s issued.
When a certificate only has one SAN field and it contains a reference to a single website, then it’s a single-domain certificate.
If that one SAN field contains an asterisk in the website name (e.g. * then it’s a wildcard certificate.
If the certificate has many SAN fields, then it’s a multi-domain certificate. Multi-domain certificates sometimes have 100 or more SAN fields (with performance penalty), and some or all of these fields may contain wildcards, creating a hybrid “multi-domain wildcard” certificate.


Thursday, August 2, 2018

Top 25 Amusement Parks

Universal's Islands of Adventure
Orlando, Florida

Magic Kingdom Park
Orlando, Florida

Le Puy du Fou
Les Epesses, France

Universal Studios Hollywood
Los Angeles, California

Universal Studios Florida
Orlando, Florida

Disney's Animal Kingdom
Orlando, Florida

Rust, Germany

Tivoli Gardens
Copenhagen, Denmark

The Island in Pigeon Forge
Pigeon Forge, Tennessee

Disneyland Park
Marne-la-Vallee, France

SeaWorld Orlando
Orlando, Florida

Beto Carrero World
Penha, Brazil

Disneyland Park
Anaheim, California

Disney's Hollywood Studios
Orlando, Florida

Disney California Adventure Park
Anaheim, California

Silver Dollar City
Branson, Missouri

Walt Disney Studios Park
Marne-la-Vallee, France

Salou, Spain

Universal Studios Singapore
Sentosa Island, Singapore

Hong Kong Disneyland
Hong Kong, China

Busch Gardens
Tampa, Florida

Kaatsheuvel, The Netherlands

Capriate San Gervasio, Italy

Paultons Park
Romsey, United Kingdom

Universal Studios Japan
Osaka, Japan