Let’s Encrypt and Google App Engine in 2017

So yesterday I set out to protect my Google App Engine (GAE) API with HTTPS. I had already set up my Google App Engine instance. I was vaguely familiar with Let’s Encrypt (https://letsencrypt.org/), although I had never used it. I also had a basic grasp of cryptographic primitives used in encryption and certificates.

There are a lot of blog posts out there about this along with a bunch of StackOverflow posts, all with varying instructions. The official ones by Google seem outdated, and the only thing I could find on Let’s Encrypt side was a bug saying something along the lines of “plz add support for GAE”. I tried a few, and by combining steps in some of them (and a lot of frustration and eventually-resolved confusion) I got it to work. I’m writing up this blog post primarily for myself (so that when I need to re-encrypt in a few months I know how), but hopefully someone out there might find it useful.


A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

Yesterday, a hacker pulled off the second biggest heist in the history of digital currencies.

Around 12:00 PST, an unknown attacker exploited a critical flaw in the Parity multi-signature wallet on the Ethereum network, draining three massive wallets of over $31,000,000 worth of Ether in a matter of minutes. Given a couple more hours, the hacker could’ve made off with over $180,000,000 from vulnerable wallets.

But someone stopped them.

Having sounded the alarm bells, a group of benevolent white-hat hackers from the Ethereum community rapidly organized. They analyzed the attack and realized that there was no way to reverse the thefts, yet many more wallets were vulnerable. Time was of the essence, so they saw only one available option: hack the remaining wallets before the attacker did.

By exploiting the same vulnerability, the white-hats hacked all of the remaining at-risk wallets and drained their accounts, effectively preventing the attacker from reaching any of the remaining $150,000,000.


New AWS Encryption SDK for Python Simplifies Multiple Master Key Encryption

The AWS Cryptography team is happy to announce a Python implementation of the AWS Encryption SDK. This new SDK helps manage data keys for you, and it simplifies the process of encrypting data under multiple master keys. As a result, this new SDK allows you to focus on the code that drives your business forward. It also provides a framework you can easily extend to ensure that you have a cryptographic library that is configured to match and enforce your standards. The SDK also includes ready-to-use examples. If you are a Java developer, you can refer to this blog post to see specific Java examples for the SDK.

In this blog post, I show you how you can use the AWS Encryption SDK to simplify the process of encrypting data and how to protect your encryption keys in ways that help improve application availability by not tying you to a single region or key management solution.

How does the AWS Encryption SDK help me?

Developers using encryption often face three problems:

  1. How do I correctly generate and use a data key to encrypt data?
  2. How do I protect the data key after it has been used?
  3. How do I store the data key and ciphertext in a portable manner?

The library provided in the AWS Encryption SDK addresses the first problem by implementing the low-level envelope encryption details transparently using the cryptographic provider available in your development environment. The library helps address the second problem by providing intuitive interfaces to let you choose how you want to generate data keys and the master keys or key-encrypting keys that will protect data keys. Developers can then focus on the core of the application they are building instead of on the complexities of encryption. The ciphertext addresses the third problem, as described later in this post.

The AWS Encryption SDK defines a carefully designed and reviewed ciphertext data format that supports multiple secure algorithm combinations (with room for future expansion) and has no limits on the types or algorithms of the master keys. The ciphertext output of clients (created with the SDK) is a single binary blob that contains your encrypted message and one or more copies of the data key, as encrypted by each master key referenced in the encryption request. This single ciphertext data format for envelope-encrypted data makes it easier to ensure the data key has the same durability and availability properties as the encrypted message itself.

The AWS Encryption SDK provides production-ready reference implementations in Java and Python with direct support for key providers such as AWS Key Management Service (KMS). The Java implementation also supports the Java Cryptography Architecture (JCA/JCE) natively, which includes support for AWS CloudHSM and other PKCS #11 devices. The standard ciphertext data format the AWS Encryption SDK defines means that you can use combinations of the Java and Python clients for encryption and decryption as long as they each have access to the key provider that manages the correct master key used to encrypt the data key.

Let’s look at how you can use the AWS Encryption SDK to simplify the process of encrypting data and how to protect your data keys in ways that help improve application availability by not tying you to a single region or key management solution.


20+ VPNs rated on privacy and security side-by-side

A VPN is now a necessity for anyone who values their privacy online. They prevent hackers, governments, corporations, and internet service providers from monitoring and tracing internet activity back to the user. All internet traffic is encrypted and tunneled through a remote server so that no one can track its destination or its contents.


Amazon API Gateway Integrates with AWS Certificate Manager (ACM)

You can now configure custom domains for your APIs on Amazon API Gateway using SSL/TLS certificates provisioned and managed by AWS Certificate Manager (ACM). Now, you can request a certificate from ACM and associate it with your API in minutes using the API Gateway Console, APIs, and CLI/SDKs. Previously, you needed to procure and upload your own SSL certificates to API Gateway in order to configure a custom domain for your APIs.

AWS Certificate Manager is a service that lets you easily provision, manage, and deploy Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for use with AWS services. AWS Certificate Manager removes the time-consuming manual process of purchasing, uploading, and renewing SSL/TLS certificates. SSL/TLS certificates provisioned through AWS Certificate Manager are free. You pay only for the AWS resources you create to run your application.

Visit here to learn more about this feature. Please visit our product page for more information about Amazon API Gateway.


Researcher Breaks reCAPTCHA Using Google’s Speech Recognition API

A researcher has discovered what he calls a “logic vulnerability” that allowed him to create a Python script that is fully capable of bypassing Google’s reCAPTCHA fields using another Google service, the Speech Recognition API.

The researcher, who goes online only by the name of East-EE, released proof-of-concept code on GitHub.

ReBreakCaptcha vulnerability still unpatched

East-EE has named this attack ReBreakCaptcha, and he says he discovered this vulnerability in 2016. Today, when he went public with his research, he said the vulnerability was still unpatched.

The researcher was not clear if he reported the bug to Google. Bleeping Computer has reached out to the researcher to inquire if Google was, at least, aware of the issue.

The proof-of-concept code the researcher released allows attackers to automate the process of bypassing reCAPTCHA fields, currently used on millions of sites to keep out spam bots.

ReBreakCaptcha works only on audio challenges in reCAPTCHA v2

East-EE says his attack only works against Google reCAPTCHA v2, the current version of the reCAPTCHA service.


An nginx config for 2017

With HTTP/2 in every browser, load balancing with automatic failover, IPv6, a sorry page, separate blog server, HTML5 SSE and A+ HTTPS.

nginx (pronounced ‘Engine X’) has excellent official documentation but putting all the logic together can take a while. An average web app in 2017 might want:

HTTP/2 support in all browsers

For speed! One of the pages on our blog loads in 1.9s on HTTP 1.1. The same page loads in 600ms over HTTP/2.

IPv6 support

If you’re working on IoT devices, which often require IPv6.

Load balancing between multiple app servers with automatic failover.

So you can upgrade your app without taking it offline.

A branded ‘sorry’ page

Just in case you break both the app servers at the same time.

A separate server that handles blogs and marketing content

So you can keep your blog independent of the main app and update it on its own schedule.

Correct proxy headers for working GeoIP and logging.

So your app servers can see the proper origin of browser requests, despite the proxy. Because asking customers for their country when you already know is a waste of their time.

Support for HTML5 Server Sent Events

For realtime streaming.

An A+ on the SSL Labs test

So the users can connect privately to your site.

The various www vs non-www, HTTP vs HTTPS combinations redirected to a single HTTPS site.

This ensures there’s only one, secure copy copy of every resource for both clarity and SEO purposes.

We encourage you to check out the official nginx docs. However…