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.
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.
Gixy is a tool to analyze Nginx configuration. The main goal of Gixy is to prevent security misconfiguration and automate flaw detection.
Currently supported Python versions are 2.7 and 3.5+.
Expose local servers behind NATs and firewalls to the public internet over secure tunnels.
Save time and be more productive. Show off in-progress work for feedback and build webhook integrations with ease. Use ngrok’s unique request inspection and replay to iterate quickly.
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.
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.
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.
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.
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…