Quando o governo americano diz publicamente que está vigiando a comunicação de estrangeiros usando serviços como Facebook, Google, etc, é bom ficar esperto e dar atenção.
No e-mail de tanta (des)informação, o Cloudflare – serviço de roteamento de tráfego mundial, se manifestou sobre o assunto, afirmando jamais ter participado de tal programa pelo simples fato de não registrar muitas informações sobre os usuário e opinando sobre a gravidade, veracidade e características do programa e quais serviços tendem a ser tecnicamente mais seguros. Tecnicamente pois, não basta o serviço for seguro, é necessário que as empresas tenha um comprometimento com privacidade e direitos civis e estabelecer procedimentos para limitar a colaboração com programas como o PRISM e outras ordens judiciais que colocam em risco direitos.
Apesar de um um pouco técnico achei o post bem informativo e se você souber inglês, vale dar uma lida.
http://blog.cloudflare.com/cloudflare-prism-secure-ciphers
Destaco alguns trechos. Os grifos e comentários são meus:
When we determine that a request is too broad, we push back to limit the scope of the request. Whenever possible, we disclose to all affected customers the fact that we have received a subpoena or court order and allow them an opportunity to challenge it before we respond.
One of the ways we limit the scope of orders we receive is by limiting the data we store. I have written before about how CloudFlare limits what we log and purge most log data within a few hours. For example, we cannot disclose the visitors to a particular website on CloudFlare because we do not currently store that data.
To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. Moreover, we believe that due process requires court review of executive orders. As a policy, we challenge any orders that have not been reviewed and approved by a court. As part of these challenges, we always request the right to disclose at least the fact that we received such an order but we are not always granted that request.
While we understand the need for secrecy in some investigations, we are troubled when laws limit our ability to acknowledge that we have even received certain kinds of requests. CloudFlare fully supports the calls for transparency today by other web companies like Google, Microsoft, and Facebook. At a minimum, we request the law be updated to allow companies to disclose the number of FISA orders and National Security Letters (NSLs) they have received. We believe this is a modest request which does not harm the integrity of legitimate investigations while allowing for an informed public debate over the use of these measures.
[…]
Breaking a SSL key is hard, but not impossible. Doing so is just a matter of computational power and time. For example, it is known that using a 2009-era PC cranking away for about 73 days you can reverse engineer a 512-bit key. Each bit in a key’s length doubles the effective computational power needed to break the key.
[grosseiramente falando SSL são conexões mais seguras, pois são codificadas/criptografadas e é necessário que os dois lados tenham o código que tornam os dados csompreensíveis. Quantos mais bits tem a chave, mais difícil é quebra.]
[…]
So, if the key were 513 bits long, you’d expect the same modest PC 132 days to break the key. These tasks are highly parallelizable, so if you have two modest PCs then you’d expect the time to break the 513-bit key to drop down to 66 days again.
[novamente, em linhas gerais: quanto mais bits tem uma chave criptográfica, mais difícil decodificá-la]
[…]
Today many web companies have largely transitioned from 1024-bit SSL to significantly stronger 2048-bit keys…
Based on the SSL survey data, Twitter has led the way, shifting 100 percent of its HTTPS traffic to a 2048-bit key in mid-2010. By the end of 2012, the following websites had approximately the amount of requests in the parenthesis shifted to 2048-bit SSL:
- outlook.com (100%)
- microsoft.com (98%)
- live.com (90%)
- skype.com (88%)
- apple.com (85%)
- yahoo.com (82%)
- bing.com (79%)
- hotmail.com (33%)
Facebook is the laggard of the bunch and today is still using a 1024-bit key for all HTTPS requests.
Google is a notable anomaly. The company uses a 1024-bit key, but, unlike all the other companies listed above, rather than using a default cipher suite based on the RSA encryption algorithm, they instead prefer the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) cipher suites. Without going into the technical details, a key difference of ECDHE is that they use a different private key for each user’s session. This means that if the NSA, or anyone else, is recording encrypted traffic, they cannot break one private key and read all historical transactions with Google. The NSA would have to break the private key generated for each session, which, in Google’s case, is unique to each user and regenerated for each user at least every 28-hours.
Novamente, em linhas gerais e grosseiras: apesar do Google usar uma chave 1024 bits enquanto outras empresas usam 2048, pode ser mais seguro pois usa uma chave diferente a cada sessão enquanto outras empresas usam a mesma sessão por um tempão.
Em tese, se a NSA estiver gravando as conexões para decifrar depois, ao decifrar a chave SSL de um usuário no, digamos, Facebook, terá acesso a informações referentes a todo o longo tempo que daquele usuário usando a Chave Y. Já no caso do Google, como a chave muda frequentemente, a NSA teria informações de um espaço de tempo bem menor.
Em face estas informações e buscando mais privacidade, minhas sugestões são:
- Pense bem no que compartilha online
- Deslogue e logue frequentemente dos serviços Google. Até aqui tenho a péssima mania de continuar logado por dias. Agora vou deslogar e logar todo dia para gerar novas chaves SSL.
- Use conexões seguras sempre que possível. Por exemplo, usando o plugin HTTPS Everywhere da EFF ( https://www.eff.org/https-everywhere ) disponível para os navegadores Chrome e Firefox
