Configuring WebSockets behind an AWS ELB

How to configure WebSockets behind an AWS ELB?

This guide walks you through the process of creating a web application such as “Chatbots” that passes the messages between browser and server. WebSocket is a protocol for creating a fast-two-way channel between a web browser and a server. It is a very thin, lightweight layer above TCP, this makes it suitable to use “sub-protocols” to embed messages. In this guide, we’ll see the configuration of WebSockets behind an AWS ELB which helps to create an interactive chat application.

The use case of a technology in software applications like Chatbots :

The combination of using Intelligent Information Management and Chat Bots can change the way Customer Service is done. Intelligent information Management is focused to automate repeatable, high-volume tasks that have been handled manually. The real-time scenario illustrates how the chat module can be useful in an Intelligent information management Platform. During the process of development of chat application, the first requisite is to implement two-way communication between server and browser. For building a real-time chat application, Websockets are the basic building block, which can offer a secure connection even over low bandwidth. In our case, we wanted to have a secure WebSocket connection over an AWS ELB and therein we faced the initial challenge. The real-time issue we faced with an AWS ELB were,

• AWS ELB doesn’t support WebSockets on HTTP/HTTPS (Layer 7).
• Switching ELB protocols to TCP/SSL does the trick, but we do not receive X-Forwarded-For header from ELB anymore, i.e. client IP information is not obtained.

The Solution approach:

• WebSockets should work on ELB with TCP/SSL protocols enabled, while client IP information should be retained.
• All the TCP traffic should be redirected to SSL, allowing only secure communication to take place.

Fixing #1: Enable Proxy Protocol on ELB

AWS introduced support for the proxy protocol on ELB. After enabling proxy protocol on ELB the X-Forwarded-For can be received even at a TCP/SSL level. Once the proxy protocol is enabled, ELB prepends a human-readable header to the request header, which contains connection specific information. For nginx, running on instances behind ELB, to understand this additional header configuration change is essentially needed. We recommend performing the configuration change prior to enabling proxy protocol on ELB, otherwise, all requests will return a 400 – Bad Request error. This post was quite helpful in having required nginx configuration:

Using Proxy Protocol With Nginx

You should be very careful about following configuration changes: You might have already noticed that the default virtual host listens to proxy_protocol. A rule of thumb for virtual host definitions is to have one default virtual host listening to proxy_protocol. The first virtual host that listens to proxy_protocol returns 400 – Bad Request to all requests received; all subsequent virtual hosts work properly.

Define default virtual host:

server {
listen 80 proxy_protocol;
server_name _; #Default virtual host
}

You might have already noticed that the default virtual host listens to proxy_protocol. A rule of thumb for virtual host definitions is to have one default virtual host listening to proxy_protocol. The first virtual host that listens to proxy_protocol returns 400 – Bad Request to all requests received; all subsequent virtual hosts work properly.

Nginx Virtual Host Configuration

server {
        listen 80 proxy_protocol;
        listen [::]:80 proxy_protocol;
        server_name xyz.com;
        root /var/www/html;
        location / {
        if ($http_x_forwarded_proto != 'https') {
        rewrite ^ https://$host$request_uri? permanent;
        }
        set_real_ip_from 0.0.0.0/20; # ELB CIDR
        real_ip_header proxy_protocol;
        proxy_set_header X-Real-IP       $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For $proxy_protocol_addr;
location / {
        proxy_pass http://172.31.23.38:8081;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        }
    }
}

The first virtual host accepts TCP traffic and all requests are redirected to SSL. Both virtual hosts listen to proxy_protocol and a custom log format is associated with corresponding access log files.

Currently, this feature can only be enabled through API’s and AWS CLI. Considering the ease of use, we’ll enable proxy protocol on ELB from AWS CLI: Installation of AWS CLI: – http://docs.aws.amazon.com/cli/latest/userguide/installing.html

We need to setup AWS access key & secret key for access AWS ELB service using AWS CLI and required ELB permission to IAM user. First, create the new policy (assuming you have an environment variable ELB_NAME defined):

Create ELB Policy for proxy protocol:

aws elb create-load-balancer-policy \
   --load-balancer-name  \
   --policy-name My-proxy-protocol \
   --policy-type-name ProxyProtocolPolicyType \\
   --policy-attributes AttributeName=ProxyProtocol,AttributeValue=True

Then, attach it to the load balancer. You will have to run this once for each port that the instance is listening on:

aws elb set-load-balancer-policies-for-backend-server \
  --load-balancer-name $ELB_NAME \
  --instance-port 80 \
  --policy-names $ELB_NAME-proxy-protocol

Make sure that you’re using https:// for the web traffic and wss:// for the WebSocket and you’re golden. Encrypted websockets behind an AWS ELB. Now if only they would expose the proxy protocol options in the console…

Set ELB Policy for Backend Servers: For Port 80:

AWS ELB Now check in developer mode wss:// protocol get the response from the server.

Conclusion:

If a lot of data will be involved and users are likely to open multiple sessions per server, the WebSockets is a better option. In this blog, you have learned about the WebSocket protocol and its approach to build real-time web applications. Besides just the basic chat application, we can make many more improvements in other web apps. This will indeed help in bringing a Intelligent Information management platform to the next level.

Contact us on +91 8888500068or visit www.AIQoD.com for more details on Intelligent Information management platform