ELB Behavior when Utilizing Backend Instances with Self-Signed Certs

There are AWS questions that I don’t know the answer to – and sometimes these questions need answers. In a case about a week ago, the following question was posed:

How does an Amazon Web Services ELB function when the backend instances utilize a self-signed certificate?

I was lucky enough to have the time to investigate. If you are just looking for the answer, see “short answer” below. For instructions (and a CloudFormation file) to allow you to duplicate my work, see”long answer” further below.

Short answer:

Yes. The AWS ELB will work with backend instances that utilize a self-signed certificate.

Long answer:

if you’d like to duplicate the test I utilized a CloudFormation file that builds this very infrastructure (an ELB, an Auto Scaling Group and Ubuntu instances running Apache accepting HTTPS connections on port 443) you can get this file from my “Snippets” repository at https://github.com/colinbjohnson/snippets/tree/master/aws/elb/elb_backend_selfsigned_cert A diagram describing the configuration is below:

ELB to BE HTTPS.png

 

After performing tests to ensure that the backend instances where healthy and serving requests I wanted to dig a bit deeper to confirm that the data was, in fact, encrypted. I went ahead and ran some requests against the backend web servers and utilized tcpdump on a backend instance, capturing data on port 443. Please note that the Security Group utilized in testing only allows port 443 inbound, so I could have run this test without filtering on “port”. A screen capture of the data captured by tcpdump is shown below:

Backend Instance - tcpdump Capture.png

I ran another tcpdump capture and loaded the data into Wireshark for visualization – the result is show below:

Backend Instance - Encrypted Data.png Notice that the capture has no filters applied – and specifically – that payload is shown as “Encrypted Application Data.” If this were an HTTP connection I would be able to view the data that was being sent. After the packet capture my curiosity was satisfied – the body of HTTP requests was being encrypted in transit.

Conclusion:

If you require “end to end” encryption of data in transit you can utilize backend instances with self-signed certificates.

 

OS X Native MFA Code Generator

Although I am happy with using Google Authenticator for multi-factor authentication I was interested in having an OS X native application – after some searching I found “OTP Manager” which I have started using as well. OTP Manager is available at http://www.stickybit.nl/ and also available for free through the App Store at https://itunes.apple.com/us/app/otp-manager/id928941247?mt=12.

OTP Manager

Configure Apache Authentication against Google Apps using OIDC – Implementation Details

This blog post will guide you through implementing Apache authentication against Google Apps using OpenID Connect. I’ll also describe (lightly) how OAuth 2.0 flows work, as OAUth 2.0 is leveraged by OpenID Connect.

How does the OAuth 2 flow work?

Once understood, the flow is fairly simple:

  1. User requests a URL: https://www.cloudavail.com/protected/, for example.
    • On this initial request the client does not send any authentication information, and the server is configured to require authentication
  2. The server redirects the user to a particular URL http://accounts.google.com/o/oauth2 for example. This URL is a parameter given to the mod_auth_openidc module.
  3. The user visits the particular URL at which they agree to share information with a third party. In this particular case, the user is authorizing google.com to share data with CloudAvail.
  4. Google then redirects the user back to a URL at CloudAvail. For example, the user would be redirected to the following URL: https://www.cloudavail.com/protected/oauth2callback – and this time, with a code provided in the query string. Example https://www.cloudavail.com/protected/oauth2callback?code=4im6WNBK5UF9. The code can then be used to request data from the Google API.
  5. When it is confirmed that the user exists (and is authorized to access a given resource) the user is the redirected to the originally requested page: https://www.cloudavail.com/protected/.

How to implement ?

As of this writing mod_auth_openidc is the only OpenID Connect module for Apache. I implemented using the mod_auth_openidc using Apache 2.7.4 on Ubuntu 14.0.4.

Create a Google Project:

  1. Go to https://console.developers.google.com/project
  2. Select “Create Project” and provide a project name and project ID.

Configure the Google Project:

  1. In “APIs” you will need to enable the “Google+ API.” See screenshot below:
    Google API - APIs - Enable Google Plus API
  2. In “Credentials” you will need to create a new OAuth key.
  3. You’ll want to select the “Web application” type
    1. for the “Authorized Redirect URI” you’ll want to provide a URL that is resolvable but does not serve content – this URL is used to receive the code that will be returned by the Google API. See screenshot below:
      Google API - Credentials - OAuth 2 Client
  4. Configure a “Consent Screen” (note that a “Product Name” is required for use of OAuth 2.0)
    1. In “APIs & auth” enter a “Product Name” and/or Logo. This will be displayed to users who are accessed to allow your application to access data stored in Google Apps.

Download and Install the mod_auth_openidc Module

# download the mod_auth_openidc Module
wget https://github.com/pingidentity/mod_auth_openidc/releases/download/v1.4/libapache2-mod-auth-openidc_1.4_amd64.deb
# enable the mod_auth_openidc Module
sudo dpkg -i libapache2-mod-auth-openidc_1.4_amd64.deb

Configure Apache to utilize the mod-auth-openidc Module

The documentation in https://github.com/pingidentity/mod_auth_openidc/blob/master/README for Google Apps is correct. One note:
OIDCRedirectURI must match exactly to the Authorized Redirect URI of your project.

Enable the mod_auth_openidc module and restart Apache

# Enable the mod_auth_openidc Connect Module
sudo a2enmod auth_openidc
# Restart Apache with the mod_auth_openidc Module Enabled
sudo service apache2 restart

Questions or Comments?

Please feel free to post either questions or comments.