Can we trust Gmail?

Gone are the days when E-mails were sent and received from desktops and laptops. Convenience, superior functionality and ease of use drove mass adoption of web based E-mail systems, such as Yahoo, Mail, Gmail, and alike. While benefits of web based E-mail are widely known, very little consideration is given to implications on privacy and security.

Quite often web based E-mail systems claim to be secure based on the fact that the communication between user’s browser and servers is protected by SSL. That is a legitimate claim, but it covers only part of the story and leaves out the big picture.

Let’s say someone sent an E-mail message from their Gmail to The first leg of communication is indeed protected by SSL and unlikely to be intercepted by 3rd parties. Not so much for the next leg - Gmail needs to locate the server, hosting the mailbox for and transmit the message text to that server. And there lies the core of the problem – the transmission is not guaranteed to be encrypted – messages can be hijacked while in transit from one server to another.

It is not unusual for communication between mail servers to be sent in clear text, vulnerable to interception. In a way this is similar to conversation over walkie-talkies – anyone who happens to be listening can possibly hear (or read in case of E-mail messages) the exchange. In case of encrypted E-mail, the unprotected transmission between servers is not an issue, since hijacked messages are scrambled and meaningless unless the interceptor has the secret key, used for encryption.

No matter how secure is the first leg of communication, i.e. the transmission of the message between the device, (desktop or phone) and the web mail provider, the confidentiality of your messages can compromised in transit to the ultimate destination, unless the message is encrypted.

Private messages must be encrypted!

SSL is fundamentally flawed - Google is the latest victim

Google reported another incident of unauthorized issuance of SSL certificates. SSL certificates are used for establishment web of site authenticity. SSL gives users assurances that the site, they are accessing, is indeed the desired web site rather than a fake, created by malicious 3rd parties.

Successful attack on the Indian Controller of Certifying Authorities resulted in unauthorized issuance of certificates for several Google domains. Individuals in possession of fake certificates can mimic Google sites and lure potential victims to give away passwords, credit card numbers and other sensitive information without realizing that sites are not genuine but rather fake.

The fundamental problem with the SSL is that it's security is is based on trust to limited number of commercial organizations (VerySign, Symantec etc.) who are given means to issue certificates to web sites. In theory, these are highly protected, honest and trustworthy organizations. In reality, if history is of any lesson, trusted certificate issuers are as likely to fall victims of an attack as any other organization (Hello Target and mass leakage of credit card numbers. Curious minds are encouraged to check out the Comodo and DigiNotar story also).

NameCoin as oppose to SSL does not rely on trusted issuers for it's names, but rather employes peer-to-peer, decentralized model. The integrity of NameCoin names can't be compromised by attacks against organizations or individuals, involved in NameCoin. There is no single point of failure. The latest Google incident as well as prior attacks on Comodo and DigiNotar are impossible to execute against NameCoin domains.

SecureDolphin relies on NameCoin for secure storage and exchange of cryptographic keys that can be used for encryption of E-mail and other forms of communication as well as secure sign-on with no password transmission over network. SecureDolphin Chrome extension provides easy and convenient tools for E-mail encryption and decryption right in the GMail window.

ProtonMail and PayPal saga - continued

I wrote about the ProtonMail before, in connection with PayPal freezing the account, used for collection of Indie Go Go donations. Checking back some time later, I found that PayPal lifted the gate on the account. When pressed on reasons for freezing the account, PayPal blamed a "human error". The explanation looks fishy to me. But, even if it is true, there still is a fundamental problem, a problem, that I've pointed to before:

Reliance on PayPal, which is subject to regulation and legislative pressure, is the Achilles' heel that drags down ProtonMail

Think of it this way: even if the ProtonMail account was frozen due to human error, the incidents highlights the possibility for PayPal to do that at any time. No, PayPal, being good citizens, likely won't do that voluntarily. Would they have to freeze ProtonMail accounts if summoned to do so? Would they have to comply with requests from FBI, CIA, NSA or other body? I think that is likely. Do I believe in PayPal's best intentions to protect their clientele, i.e. ProtonMail in this case? Absolutely! However, make no mistake, when the question comes to protection of one client vs. loosing the business or affecting hundreds, thousands or million others the choice is likely to be very clear. Is it possible that PayPal finds itself in under treats to be shut down or comply? Yes. Check out the LavaBit story for a recent account of a company being shut down for standing up and backing it's users

I truly hope that ProtonMail learns the lesson and finds ways to eliminate dependencies on centralized services or infrastructure. Going peer-to-peer is the only viable path...

Running NameCoin under CentOS and RedHat 6.2

This is a follow-up to the my notes on Compiling NameCoin under CentOS and RedHat 6.2. After the successful compilation, I've tried to start the software and... got a core dump. Running it under debugger quickly revealed the source of problem.

Upon startup, NameCoin daemon attempts to load wallet keys or generate a new wallet if one does not exist (i.e. the wallet.dat file is missing in the data directory, set in the configuration). In either case, it uses OpenSSL to create or load an Elliptic Curve (ECC) key. ECC keys are initialized with certain parameters. Normally, OpenSSL users would use EC_GROUP_new_by_curve_name API call and pass in the unique identifier of the pre-configured parameter set that was shipped with OpenSSL. Apparently, not all OpenSSL distributions are created the same. The version on CentOS and RedHat 6.2 is missing the NID_secp256k1 definition, which results in failure to initialize the key on these platforms.

I've created and submitted a patch, based on ideas and some code from similar patch for BitCoin. However, my patch is still not accepted. Feel free to apply it manually in the mean time.

Obviously, this applies to Fedora also, as I've mentioned in the previous entry

ProtonMail did not escape the Big Brother!

ProtonMail is the most recent addition to the family of secure communication solutions (there are a few others that I will cover in separate blog posts). According to their web site ProtonMail is fully anonymous and confidential web E-mail system, i.e. Yahoo Mail or GMail but better: they don't have access to your E-mails and don't keep track of users, accessing the service. What can be better! No wonder the ProtonMail Indie Go Go campaign managed to attract remarkable 300K in a month or less since the launch of the campaign. The news broke a few days ago that the ProtonMail campaign ran into issues with PayPal, who handles some of the payments, contributed through IndieGoGo. Paypal froze ProtonMail account and refuses to release accumulated funds. At the same time, contributions made through BitCoin remain safe and fully accessible to ProtonMail. The news highlights an important fact largely overlooked by broad public and, specifically, enthused ProtonMail campaign contributors: no system, solution or tool is secure, safe or anonymous unless it is fully distributed and peer-to-peer. Moreover, the weakest chain defines the security of the overall system. In case of the ProtonMail the reliance on PayPal that is subject to regulation and legislative pressure is is the Achilles' heel that will drag down ProtonMail if not eliminated ASAP! True confidentiality and anonymity are impossible as long as there is slightest dependency on centralized, governed solutions or infrastructure.

Building NameCoin under CentOS and RedHat 6.2

I am working on a project that runs on CentOS Linux 6.2 and requires operation of a customized NameCoin daemon and client. The first step to customize NameCoin is to build it on the target platform from source. Instructions at the NameCoin GitHub page are quite brief and are tailored to Windows build. There is a bit more at NameCoin Wiki. However, even that is outdated, incomplete and do not quite work for CentOS (and RedHat for that matter). I think they are written for Ubuntu. Here are my notes from tweaking the NameCoin build procedure to yield a successful build of the daemon and the client:
  • Install required prerequisites yum install boost-static db4-cxx.x86_64 db4-devel.x86_64. boost-static is an umbrella package that brings in all other packages necessary for compiling against boost. NameCoin build instructions ask to download dependency libraries and place in the namecoin/lib directory. With these instructions there is no need to do that.
  • Download the source code from GitHub or do git clone
  • Open the Makefile in namecoin/src directory and remove the -l boost_chrono$(LIBBOOST_SUFFIX) line. There is no or libboost_chrono.a library under CentOS as required code/symbols are included in other boost component libraries
  • Go to namecoin/src directory and type make
  • Enjoy the result!
P.S. The same procedure can be used for RedHat and other derivatives such as Fedora. Further tweaks may be necessary on Fedora. On RedHat this is, pretty much, guaranteed to work as CentOS is an exact clone.