[Cryptography] HTTP should be deprecated.

Wed Nov 13 16:59:36 EST 2013

Hi Lewis,

Thanks for reaching out.

I feel terrible about security and data integrity in America, but also 
in the world as a whole.

We have thoroughly explored Canada and Europe as options for our HQ and 
infrastructure. Problem is, my research shows that very few first-world 
countries are even remotely outside the reach of the USG.Sure America 
has the Patriot Act and National Securtiy Letters to worry about, but I 
don't think a lack of these options will stop the USG from obtaining 
data they want.

What we've done is bring extreme awareness of InfoSec to the table. 
Every step of the way we work to find the best solution using readily 
available technology. Is it perfect or ideal? Hardly. But we think it 
better to do our best than to throw our hands up in the air.

Here are 10 quick examples of measures we take that I could think up for 
you on the spot:

1) Isolation testing for shared/virtualized environments
2) Very minimalistic logging, and for very minimalistic period of time
3) "Scorched earth" prepared (whether it be a natural disaster or an 
overreaching NSL, we have plans on how to make our infrastructure 
disappear and reappear... elsewhere -- in far off jurisdictions if 
necessary.)
4) An International staff that won't come to a halt even if my US staff 
was "compromised".
5) PGP email, private XMPP, SilentDesktop, TextSecure and RedPhone 
contact support for customers with severe privacy concerns (at no extra 
cost, just ask)
6) Privatized IPMI for servers (on a private VLAN and IP restricted -- 
not public, which would be a clear hole for the USG)
7) An owner who isn't afraid to stand up for what's right, even if it 
means personal sacrifices.
8) Every member of our staff is trained and tested regularly on social 
engineering awareness and resilience
9) Internally we avoid "the cloud" or at least always have a secure 
alternative and the awareness/diligence of knowing when to use which.
10) We pen test our own software and infrastructure regularly and have 
rigorous daily routines regarding the update of software and reviewing 
the latest vulnerabilities.

In short, we work to be very vigilant about privacy and security, it is 
at the core of our business. That said, it is not our goal to harbor 
criminals. In the case of a valid warrant (one that doesn't violate 
rights and has gone through the proper transparent process -- e.g. not 
an NSL) for a specific user who is clearly breaking laws, we will turn 
over relevant information. In these cases, we notify the client before 
turning over the information. It's mass surveillance and/or a lack of 
due (and fair) process which we will not participate. We see sensitive 
things like anonymous journalism, human rights activists, etc. as 
perfect use cases for our infrastructure.

We think that having trust in the people in charge of the infrastructure 
is more important than the jurisdiction.

Of course, our upstream providers (PEER1 [a Canadian company fwiw] or 
their upstream providers) could potentially cooperate with tapping of 
the pipes without us knowing. Our attempt at mitigation is making SSL 
extremely affordable to our customers (we have the lowest consumer rates 
in the world on trusted EV certs, at least that I know of), managing the 
private keys with extreme paranoia and offering managed implementation 
of PFS for clients who need it.

Could we provide more security/privacy? We perpetually believe so, and 
we're always working to make it happen.

Kind regards,
Alex

> Lodewijk andré de la porte <mailto:l at odewijk.nl>
> Wednesday, November 13, 2013 1:32 PM
>
> How do you feel about security and data integrity as an American 
> company? I'm quite sorry but I cannot deal with any company connected 
> to America regarding hosting, although I really do love the mentality 
> presented on your website. The patriot and related acts make it simply 
> impossible to achieve the level of security that my business needs. If 
> it is possible, please convince me!
>
> All the best,
> Lewis
> Alex Stanford <mailto:ahstanford at gmail.com>
> Wednesday, November 13, 2013 9:21 AM
> HTTPS can be a problem for CDNs for a couple of reasons:
>
> 1) In order to truly cache from the edge all the way back to origin 
> over HTTPS you have to juggle certs at each PoP and track which certs 
> are valid, at least in the CDN architectures I am familiar with. One 
> trick we've used is to allow HTTP or HTTPS for static files on origin, 
> but force dynamic pages to HTTPS - then the CDN caches via HTTP but 
> serves via HTTPS. This implementation works quite well for us.
>
> 2) Certs are generally tied to an IP or set of IPs and applying 
> multiple certs to one IP can prove difficult. So, CDNs assign IPs at 
> each node specifically for a particular hostname in order to provide a 
> custom SSL cert to a customer. So, a customer requiring custom SSL may 
> thereby require dozens of dedicated IPs.
>
> At my business (fullambit.net) we're working to overcome these issues. 
> Our shared hosting accounts come with a dedicated IP, a trusted SSL 
> cert, anycast DNS and CDN service included by default. However, this 
> default CDN service is limited to a shared CDN hostname. This is 
> usually not a concern for customers, and other CDNs offer the same 
> type of deal (cdn77.com for example). It's when we come to custom SSL 
> certs on the CDN that we start to stand apart. We only charge 
> $27.99/yr for a Thawte 123 DV certificate or $109.99 for a Thawte Web 
> Server EV certificate. The only caveat is that we ask customers to 
> commit to at least 1TB/mo for the entirety of the year, at a rate of 
> $39.99 per TB. We're also flexible in offering other certificates. 
> ($8.79 /yr for RapidSSL, and we can do Wildcards too, for example)
>
> My point being that while it is a challenge to offer SSL as a CDN, it 
> is also entirely possible, and I would assume even more so for big 
> companies like Akamai. CDN's and caching really shouldn't be part of 
> the equation when it comes to HTTPSing the Internet.
> Eric Mill <mailto:eric at konklone.com>
> Monday, November 04, 2013 2:01 PM
> I'm very pro-HTTPS for as many places as possible, switched to use it 
> on my own site, and documented how to do it 
> <https://konklone.com/post/switch-to-https-now-for-free> in detail.
>
> But I'm also very pro-"it should be easy to publish things on the 
> Internet", and key management *is* a pain in the ass. Requiring it 
> Internet-wide would raise the barrier for people new to web publishing 
> to get started, and/or make more people just use a *.wordpress.com 
> <http://wordpress.com/> or *.whatever.com 
> <http://whatever.com/> domain, rather than bother getting their own.
>
> Instead, we should establish very clear norms about HTTPS for services 
> and web applications of all kinds. If you have the ability to add 
> HTTPS support, you should, and the mandate is especially clear for 
> hosting services.
>
> For example, one glaring gap for me is Github Pages. It's impossible 
> to use HTTPS if you host something via Github Pages, whether or not 
> you use your own domain name (unless you do something expensive like 
> put CloudFront in front of it).
>
> Caching with HTTPS is a problem. One source of reluctance for major 
> platforms to support HTTPS is because CDNs like Akamai raise their 
> prices drastically if you want HTTPS. That's a major market force that 
> guides the decision companies make, and it's one we should commit 
> ourselves to changing.
>
>
>
>
>
> -- 
> konklone.com <http://konklone.com> | @konklone 
> <https://twitter.com/konklone>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> Peter Saint-Andre <mailto:stpeter at stpeter.im>
> Monday, November 04, 2013 12:28 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Some of us are working on that for some protocols:
>
> https://github.com/stpeter/manifesto
>
> Peter
>
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSd9lbAAoJEOoGpJErxa2pzhIP/iAdZkNEdgWRrt9N/7Tc06IK
> 3U9zDSzve6BglycwKsCmB8e9+dOuXjw383PiiydbiMDkmUOj7uvkiI069TImfk4E
> Q49WKlBX3rNeqSuk3OAE4CgsnQLxxKns52q4TqfunsDgQS4EJL0xb6VH/O62JxFO
> vjX6N0l6XYS/VnjJJi4jsqAsFjwsx0sVHP30bpvNNqTr511RRSdIa3udUE3CY8mP
> Hf/8V6x6kLQENXgW4lYNyLMG3r4Q3/BkHkurLuw33jdCxNu6Wx4RB5xFPCWKFQyS
> XgrYUBDRfVFHB0OqiukFE0uBqVvuTB9UH47zZiFuN3GM55UJ4TE8gks4W2v7Ku/n
> vby+u/vToqZGGLJYwd2AzyfUag629KhnCbMJ1arp+fd5hMx5O3mbvzB7sJu92Suj
> ZYB3LIkWUc/F5EJXCZN73HhxiyFbkWi5kVfPLkd5UybpI9CNd9Kglh00TBryZ5Ws
> dGF/cOuwtWVOoNn5VeJDFm9MRbDnICwkpguuIdWCZGC8e30A7e4cuR3OFrNVkkfg
> 2ZmFaiVPN93aKeWiXclCkdTwxCXHoRByfSO89Z6QHDhQqbSQ6WMKaidPPbphGyjl
> yyPUG3EsleZQBWdSic+5dgV4TIu2EMzY9IAYGuuNZruFRvr/ZUDnNosIbdg3UnXH
> yNFG+7eTIcVkax5Riqgz
> =S+19
> -----END PGP SIGNATURE-----
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> Greg <mailto:greg at kinostudios.com>
> Monday, November 04, 2013 10:50 AM
> Could someone please forward this message to the Elders of the Internet™?
>
> It's time to make encryption mandatory in all communication protocols.
>
> Thx,
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also 
> sharing with the NSA.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131113/e4412886/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131113/e4412886/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1086 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131113/e4412886/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1190 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131113/e4412886/attachment-0002.jpg>