Thursday, we posted advice on creating a custom domain name for an application developed with Google’s App Engine. In this post, we will learn how to add SSL support and force the App Engine application to use only SSL.
Start by obtaining an SSL certificate for your domain from an authorized certificate authority. Consider following elements while buying the certificate:
- The name of the certificate should match the domain name. The certificate can be a single domain or multidomain but should not be a wildcard certificate.
- The certificate should be signed using a strong signing algorithm such as SHA-256.
- For financial and other sensitive applications, it is best to have an extended validation for the certificate.
Before adding SSL support, make sure you have added a custom domain name for your application. If not already done so, you can refer to this blog and follow these steps:
- Log in to the Google Cloud Platform Console.
- Navigate to “App Engine” and “Settings” as shown in the following screenshot or enter https://console.cloud.google.com/appengine/settings/certificates in the address bar. Click on the “SSL Certificates” tab and then on “Upload a new certificate.”
- Select the certificate and the domain to which the certificate needs to be attached.
- Confirm changes by accessing your application over HTTPS.
Regardless of whether you use a custom domain for your application; it is important to note that by default HTTPS is not strictly enforced for App Engine applications. This means your web application will be available over plain HTTP and HTTPS. HTTP is a clear-text protocol, and sensitive information is sent unencrypted over the network; that is not safe. Now let’s see how we can enforce HTTPS for the applications developed using App Engine:
Add these two lines in the file app.yaml in the folder WEB-INF:
url: .*
secure: always
For Java applications, we can achieve the same effect through the file web.xml:
<web-app>
………
<!– Enforcing HTTPS –>
<security-constraint>
<web-resource-collection>
<web-resource-name>HTTPS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
………
</web-app>
HTTP Strict Transport Security
The preceding method of enforcing HTTPS works via redirection. If a user issues a request over HTTP, it will be redirected to HTTPS. The problem with this initial HTTP request is that it is vulnerable to a man-in-the-middle attack, allowing an attacker to redirect the user to a malicious page. For example, a user connects to an open Wi-Fi service at an airport or café and requests web application over HTTP. Because this Wi-Fi is controlled by the attacker, the user is redirected to a malicious page instead of the real web application. To protect users from such scenarios, a web application can make use of the HTTP Strict Transport Security (HSTS) header. Through HSTS, a web application can instruct a browser that the site can be accessed only using HTTPS.
HSTS can solve this problem only if a user has previously accessed the web application over HTTPS.
To use HSTS headers with the App Engine, the domain needs to be whitelisted by contacting appengine-security-headers@google.com.
Reference
https://cloud.google.com/appengine/docs/java/console/using-custom-domains-and-ssl
This blog post was written by Piyush Mittal.
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
