I wonder if it would be possible to automatically flag ngrok sites for manual review based on certain criteria. E.g. if the phrase "citibank" appeared on the site, it would appear in a moderation queue.
Though there may be bulletproof ways for criminals to bypass such automatic scanning. For example, I've heard of criminals creating two versions of their site: One, a harmless site, that you get if you type in the domain name cold, and then a criminal one, that you only get if you have the right referrer header or query string. Which makes it difficult or impossible for an outside entity to see the illegal content without access to the spam email, referring site, or what have you.
I don't know much about ngrok, but I take it you can tunnel SSL over it such that it's impossible for ngrok to inspect the contents of your traffic. Which would rule another viable strategy: Monitor traffic for suspicious keywords, thus bypassing the cloaking techniques described above.
Any other techniques for automated flagging that I might be missing? Maybe some kind of content-agnostic traffic analysis that spots a likely spam fingerprint, e.g. certain chronological traffic patterns?
The post already mentions why he doesn't want to do this.
> One of the core tenants of the ngrok.com service is that it does not inspect your traffic at all beyond reading the header field necessary to perform the multiplexing.
Yeah, I'm just thinking one could relax that policy--if there were actually a viable strategy for flagging sites, which there may not be.
Unless you're tunneling SSL, you can't know that ngrok doesn't inspect your traffic. Promises of privacy that are based on the honor system aren't worth much, at least to me. I'm not at all attacking the honesty of the ngrok operator; I'm just stating a generality about security--one that applies regardless of how much you think you trust any particular actor. For two main reasons: 1) The actor may not be as good as you think, and 2) even a truly good actor can be compromised in a variety of ways.
Therefore, to me at least, a promise not to inspect traffic has little or no value. And if that promise has no value to users of ngrok, perhaps it could be relaxed in favor of protecting the long-term viability of the service.
That being said, the caveat stated above still applies. There's no point in relaxing the promise unless there exists a viable flagging strategy. And such a strategy may not exist, owing to the problems I described in my previous post.
I think ngrok is doing the SSL termination, so they decrypt to plaintext before forwarding. Otherwise they would have to distribute the private keys for the *.ngrok.com certificate to every enduser?
If each user created their own key for a .ngrok.com subdomain, could ngrok then sign those, rather than giving out the private key? Would user agents consider the subdomain's signed cert sufficient in that case? This is an odd little corner of SSL logic that I'm not as clear on.
Sadly not. There is no delegation of authority for domains. If you are trusted to sign, you can sign anything. ngrok does see and ignore all of the decrypted traffic before it re-encrypts through the tunneled connection. This will change soon with SNI-based tunnels though.
Though there may be bulletproof ways for criminals to bypass such automatic scanning. For example, I've heard of criminals creating two versions of their site: One, a harmless site, that you get if you type in the domain name cold, and then a criminal one, that you only get if you have the right referrer header or query string. Which makes it difficult or impossible for an outside entity to see the illegal content without access to the spam email, referring site, or what have you.
I don't know much about ngrok, but I take it you can tunnel SSL over it such that it's impossible for ngrok to inspect the contents of your traffic. Which would rule another viable strategy: Monitor traffic for suspicious keywords, thus bypassing the cloaking techniques described above.
Any other techniques for automated flagging that I might be missing? Maybe some kind of content-agnostic traffic analysis that spots a likely spam fingerprint, e.g. certain chronological traffic patterns?