vabmit

I block tor from many of my servers. I started noticing that whenever I had an issue with someone attacking a server the source traced back to an exit node. What I found when I looked at the traffic coming from the exit nodes was that the vast majority of it was malicious. There was a massive amount of automated password guessing, exploit attempts, and attempt to connect to botnet controllers/backdoors.

I'm all for anonymity. However, until the tor project puts some effort into outbound traffic filtering for exit nodes it is too much of a time sink and headache not to just blackhole it all on servers that either do not serve public content or where anonymity really isn't needed/justifiable.

I put the code I use to block tor exit nodes in the public domain. You can download it here: https://github.com/vab/torblock

Yes, exactly. The client is able to install and run a local proxy/translator application on their machine (currently, it's called a "bridge"). Their IMAP client connects to it and it interacts with ProtonMail's APIs over HTTPS. Since the bridge runs locally, the private key is locally decrypted with the client's password. The password is never sent to the server. The decryption takes place locally in the bridge software running on the client's computer.

If a user resets their single password or encryption password, they lose access to their previous e-mail. This is because what essentially happens is that a new PGP keypair is generated and the Secret Key is encrypted with the new password. Since we do not have their old, lost, password we cannot access their secret key to decrypt the e-mails (and subsequently re-encrypt them with the new Public Key).

IMAP support is coming very soon. Engineers are working on the code, now. It's a more difficult task than people would imagine because the implementations of the IMAP standards by some clients (like Outlook) is a bit... "interesting".

The mailbox encryption key is static. There is no need to re-encrypted all the mail when it is changed. Since the PGP Secret Key is only decrypted in the client browser or app, there is no need to transmit the decryption password to the server.

We've been using client certificates at MIT for more than a decade. Many people like them. But, most people hate them. As others said, the usability is the primary issue.

The specific issues are:

1. You have to install a client certificate on every device you want to use. And, you have to keep that certificate up to date. If you use multiple web browsers (for say UI development testing) you have to install and maintain the certificate it each one. MIT currently issues client certificates with a validity period of slightly less than one year. That makes for a lot of lost time every year for students, staff, and faculty, spent re-installing client certs.

2. The certificate can be stolen just like a password. But, there is no easy way for the client to revoke a stolen certificate. Many CRL list implementations are lacking or fully absent. There for, organizations that depend on client certificate authentication typically depend on certificate expiration to re-secure compromised client accounts. (See #1 above)

3. Client certificates are not supported by all web servers. The major players support it pretty well. But, there's been a proliferation of specialized, micro, and nano web servers over the last several years.

4. You have to invest in securing the signing key for the client certificates. This usually means a decent HSM which costs on the over of $x00,000USD. At MIT for example, there is a web site where anyone can go at any time to generate a new client certificate (again, see #1). This site needs to be able to perform signatures constantly which means the signing key needs to be accessible 24/7 online some how.

5. Proxies are a problem. If you try and terminate the TLS connection early, the client certificate related operations are not "proxied back". Some proxies like HAProxy will allow you to pass back environment variables set during the client certificate authentication process. But, that is obviously not the same as having the final destination webserver performing validation. This has become much more of an issue with the invention of ClouldFlare's TLS proxying CDN.

6. If you implement logic to expire certificates at the end of a customer's subscription or enrolment period, it can cause significant headaches with processes where it would be helpful to still be able to authenticate them. For example, if a customer's subscription to your SaaS site expires and you want them to be able to review with out inadvertently sharing details of their account with others. Or, if a student has graduated but they still need to pay some unpaid parking tickets. MIT runs into this issue often due to its use of client side certificates. If you extend their certificate well beyond the end of their system authorization, you have to put a lot of complex authorization code in all of your local apps and websites. While client certificates only provide authentication and not authorization, many implementers use client certificates for both simultaneously. This is especially true when protecting web content and web sites with client certificates.

Code allowing external access (IMAP etc) to mailboxes that would allow you to download all your mail is in development now. Some IMAP clients (cough Microsoft cough) have "interesting" ways of interpreting/implementing the RFCs. So, it is taking somewhat longer than expected.

2fa is being tested on the internal development site, now.

The move from .ch to .com was done in an attempt to deal with the poor search ranking. It was done because the best guess was that Google was "geocoding" ProtonMail as a Swiss-only relevant website and there for ranking it poorly in google.com results. ProtonMail actually did not want to move domains. There was an significant internal struggle over the decision. Up until the change, ProtonMail had actually been promoting the .ch domain as an advantage since the US Gov't/FBI would need to go through the Swiss authorities to seize DNS control of the domain (unlike .com). That is the reason that .ch remains available for customer e-mails.

A lot of people said hire a lawyer. I think that's wrong. I would just move on and find another job and forget about this start-up. My guess would be that either you had bad luck and got involved with a bad founding team or that there were performance issues/issues with your working relationships/personality. Either way just moving on is the mature thing to do. I would never hire anyone who mentioned the word "lawyer" over a firing (let alone actually sued a company) that's just too much of a risk for a small company/start-up. Talking to other engineers at the company to "warn them", or better yet, gain an understanding of why you were let go would probably be helpful in your own career development. When I've had to fire a technical person, I've always gone over the matter with their co-workers to make sure there is coverage and not a skills gap with out the person. If you do sue, your name will most likely show up in public court filings. That could end your career with start-ups unless the start-up turns out to be a total publicly visible disaster. The economic damage to your reputation will likely outweigh any awards from the court (if you even win the case)... especially after you pay your legal team.

Were your options really "clawed back" (meaning recouping compensation that has already been given) or did they just not vest? Unless you mean founder equity or RSUs instead of options, I can't see how you would have had them after 51 weeks. Usually, people vest like 25% of their promised equity compensation after 1 year (the "cliff") and then a small percentage each additional month until they fully vest after 4 (or sometimes 5) years.

Remember how differential cryptanalysis was discovered by the academic community and subsequently the DES S-boxes pre-dating that discovery were found to specifically make DES resistant to that attack?

Basically, because people thought it was safe. It didn't seem significant to use the same prime since the key exchange process involves both Alice and Bob generating a secret. Solving the discrete logarithm of g^a mod p was still thought to be intractable given a large enough (1024bits) p.

As to the technical reason why the DH parameters were reused - speed and efficiency. A DH key exchange would take longer if you had to generate those parameters each time.

I just want to point out that the P-curves need not have unique features that allow for more efficient computations during code breaking in order to be "weak" or "backdoored". Simply the fact that the curves are standardized may allow expedited code breaking. We saw this with POISON NUT/CORAL REEF (where specialized hardware (PIQ Blade), pre-computation work, and an otherwise fine small standardized set of primitives allowed for rapidly broken encryption).

The problem is that since the qualities of these special semi-primes that allow SNFS to work on them is not very well understood there is not an easy way to test if an attacker could use SNFS rather than GNFS. Additionally, running SNFS (or GNFS) on a semi-prime is not guaranteed to result in a factorization. Unlucky polynomial choice, for example, is one of the reasons such an attempt may fail. So, you could expend massive resources attempting to perform an SNFS factorization and not have a clear answer.

If you go into the Linux kernel (or other software) and look at the randomness testing and primality testing code, you can see that it is not extremely complex. Basic checks include things like making sure that a stream of data from /dev/random is not just a repetition of the pattern 1010101010101010... Prime candidates are typically checked with trail division routines. After making it through the basic checks, software will typically do something more advanced and computationally expensive. Usually, a Miller-Rabin test is run on the candidate number. That is usually all there is to it. Extensive verification of cryptographic primitives ("random" large primes, etc) is typically not feasible.

I been involved in the cryptography/security community for many years. I continually see privacy/security start-ups struggle. There are lots of reasons. But, I think the key one is that doing something online securely will always be more difficult and expensive that doing it insecurely. This truth was instilled like a law of physics when the internet was first designed.

There's only a certain number of people that are deeply passionate enough about their privacy to put in the extra effort or pay the extra cost. So, companies in the space tend to plateau after 2-4 years. They essentially saturate their markets and the (rather static) size of these markets are rarely large enough to sustain the company (this is especially true when hardware is involved in the business plan). In cases where they are sustainable, I have seen it be at the level of "life style business" rather than exponentially growing startup that can IPO at a level that will provide investors a significant return. While there have been exceptions over the years, I would caution people on HN from doing privacy and security startups until you sit down and honestly and truthfully estimate the size of the market that you are targeting.

Us old folk remember another secure phone company before SilentCircle/Blackphone - CryptoPhone. I have talked with some friends that remember the CryptoPhone product failure. Some thought that the Snowden revelations changed things. They thought that such companies would be viable now due to mainstream market apatite. But, I think over the next few years we'll see more evidence that this isn't the case.

Privacy is an area that is very easy to get passionate about and become emotionally invested in. But, it's probably not a great space for your startup (or for your investment).

There is no need to modify the ISO image on the server's disk just as there is no need to modify the ProtonMail source code on disk (both of which would make it more likely to get caught). The NSA has been known to have the ability to modify the ISO image as it was downloaded in a single selected TLS stream. So, if TLS is compromised the attack on a Linux Distro is the same as an attack on ProtonMail.

But, where did you get that public key that you're using to verify the signatures? Personally, I got that public key because it was included in an ISO image that I downloaded over TLS from website. So, if that TLS session was compromised, a fake public key could have been inserted in the ISO. Or, the copy of GnuPG in that ISO could have been modified not to complain when the signature of certain pieces of code did not validate.

Ideally, you should be able to use the WoT (Web of Trust) to validate the public key that comes with the ISO (validating that the copy of GnuPG, glibc, or the Kernel has not be modified to mess with the signature validation is much harde). But, have you ever looked at the signatures on the public keys that most distributions use to validate their software releases? There are usually no signatures at all. They keys have no WoT links at all. They don't even use it. One example of this is RedHat Linux.

I actually wrote a document that describes how to do Strong Software Distribution with PGP: https://cryptnet.net/fdp/crypto/strong_distro.html Unfortunately, no one really does it.

Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so...

1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it goes much beyond the physical servers. Simply locating servers in Switzerland doesn't provide much protection for users if you're an American company with US bank accounts. For example, choosing to run on German or Irish AWS servers doesn't really buy you much. But, ProtonMail not only has all of its servers located in Swiss datacenters, it also: 1) Is a Swiss corporation fully under the jurisdiction of Swiss law (which also means it operates under strict customer data anti-retention requirements) 2) Holds its funds in a Swiss bank 3) Has corporate officers that reside in Switzerland 4) Offers .ch e-mail addresses and a .ch web interface that cannot be taken control of through US courts and that are resolved through Swiss DNS servers 5) Is using a non-US (Swiss) Certificate Authority (QuoVadis) for its certificates.

2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. It also includes any software that runs on platforms that have patches distributed over TLS. That is nearly everything. It's no more difficult to insert malicious code into web apps than it is to insert it into mobile phone apps, desktop apps, or operating system patches when working with a compromised trusted TLS connection. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. There are devices out there with trusted hardware and embedded keys and some groups are starting to make use of proper TPMs. But, high quality trusted platforms are beyond the reach of most consumers and developers. I know of no platform that would catch the insertion of malicious code by a determined third party with the ability compromise a TLS session in the release and/or development cycle. If webapps are faulted and everyone is using a webapp (github) to develop, well then, everyone is essentially equally compromised. The same goes for distributing updates or public keys for validation of code signatures.

3. The company did, in the early days, see Lavabit as a inspiration. But, our systems are very different. Our systems are "can't read your mail" not "promise not to read your mail". Proton has no need to avert its eyes. There is no "plaintext in and plaintext out". There is no transmission of the private key decryption passwords back to the server. I don't think your comparison holds. The way Proton works is that the encryption is done in the browser. A non-encrypted private key is not stored, or ever sent to, the Proton servers. An openPGP keypair is generated in the browser by the user. The public key is sent to servers and stored in a database. The private key is encrypted in the client's browser, with a passphrase the client enters, using the opensource openpgpjs library. That encrypted (with a password that is never sent back to the Proton servers) private key is sent to the Proton servers and stored in a database. When a user logs in, their encrypted openPGP key is sent down to their browser with their public key encrypted e-mail. Their web browser then decrypts their private key and uses it to decrypt their email on the local computer. We never have to avert our eyes from their passphrase because it never transverses our systems. The decryption is done locally. Obviously, it would be better for us not to store the private key (even though it's strongly encrypted). But, that's just not practical for a webmail application.

So, I'm sure everyone is wondering: What would a TLS based ProtonMail compromise look like? Well, modified code (nefarious javascript) would be injected into the TLS stream that would send the user's decrypted private key and/or private key pass phrase to a third party or otherwise expose it (as invalid packets, etc) in the stream. Or, carefully selected cryptographic primitives would be inserted into the software. I contend that these are the same vulnerabilities someone faces downloading GnuPG from it's distribution sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates.

And, I'm also sure people are wondering: What would a US Government compromise of the ProtonMail servers look like? Well, I'll leave the details out on how the US Government might get their hands on Swiss domiciled servers... maybe something like the time they cut through a datacenter wall at MIT in the middle of the night to get the early PGP code. Let's just assume they have the servers. They'd first have to break the disk encryption. Once they broke the disk encryption, they'd have to break into the database. Once they did that, they'd basically have a bunch of AES encrypted keys that they'd have to run password guessing attacks on.

ProtonMail is trying to bring cryptography to the general population to protect the basic human right of privacy. We are doing webmail the best possible way webmail can be done because webmail is the primary method of communicating for the vast majority of people today. We are not going to get our grandmas to sit in Faraday cages and work on trusted platforms with one time pads that they exchanged at their church groups and yoga classes.

There is no security through obscurity in what we're doing. Honestly, I'd be honored if you took a look. We use Signal internally. I've read through the code and was very impressed. I couldn't find a single flaw that I could exploit. Perhaps, you'd even be willing to do a consulting engagement to audit us?

Verified. ProtonMail received no additional requests for money. And, those are the attackers' words. The original attackers claim they stopped. They hit many other Swiss companies and stopped after they were paid, as well. They are screwed now (and seem to be panicking a bit) because the size of the secondary attack was enough to knock a portion of Swiss internet infrastructure off line, anger some high profile businesses (including banks), anger the Swiss Government, and cause the matter to become a high profile case for Europol.

The problem with ProtonMail is that their business model and brand are based on being domiciled in Switzerland and operating under Swiss law. Their datacenter threatened them if they didn't pay the attackers and no other datacenter in Switzerland was willing to take them. They tweeted out for help finding one after everyone with sufficient bandwidth to withstand the attacks rejected them: https://twitter.com/ProtonMail/status/662212032368889856 Eventually, one came forward. But, the ransom had already been paid at that point.

CloudFlare was the first company ProtonMail called (with in 5 minutes of the DDoS starting). Unfortunately, they couldn't help ProtonMail. But, thanks to @rdl for responding to a txt on his cell phone at an inopportune time and mobilizing CloudFlare's sales and engineering teams to talk with Proton (during the company's retreat no less)!

For all the people getting nasty and arm chair quarter backing this on little to no information or trying to claim credit for things they did not do- understand that once you start working in venture funded startups pretty much everyone knows each other and many people have worked together before.

Because ProtonMail would have been required to give CloudFlare encryption keys that would have 1) allowed CloudFlare to inject JavaScript to steal decryption passwords and keys 2) Allowed CloudFlare to collect metadata on traffic for individual users

ClouldFlare are a bunch of great guys. And, they wouldn't do any of that unless they were delivered a National Security Letter forcing them to.

If ProtonMail signed up with CloudFlare, like HushMail did, ProtonMail would have no way to know if these types of code modification attacks or metadata collections were happening.

And, as people saw with Hushmail, since CloudFlare does not do SMTP proxying (filtering/challenging) a DDoS could have still taken down ProtonMail's mail servers offline. While CloudFlare allowed Hushmail to get it's website back online, mail to my Hushmail account is currently delayed by several hours due to DDoS of their mail servers.

From https://hushmailstatus.com/ :

"We're investigating reports of incoming and outgoing email delivery delays. We'll update this page as more information becomes available."

For a site the size of ProtonMail, $6K is the cost for protection for a single month. Most of the companies that offer this kind of protection require you to sign a one to three year contract.

There are two kinds of protection, basic HTTP/HTTPS and DNS only (done with DNS and CDN like servers co-located at peering points), and traffic filtering that is done through BGP with and a GRE tunnel. While you can get basic HTTP/HTTPS and DNS from CloudFlare for $200/month on a business account, what ProtonMail needed was a BGP/GRE which at it's lowest price is a multiple and an order of magnitude more expensive.

Protonmail's e-mail servers were off line for multiple days. With an outage of that length mail will start to bounce. It depends on the local configuration. But, 3 days/72 hours is pretty standard.

No. They ran the coins through a Coin Mixer: https://coinmixer.net

Aside from risk mitigation there are a few other things that no one has mentioned. First, shorting. If you sell 3 month US Treasuries that you do not have because you think that you are going to be able to buy them later at a lower price, you may have to buy them at 0% if they are called. Second, there are a number of funds that have constrained investment choice. For example, Fidelity has a short term US Treasury fund that must only invest in short term US Treasuries. And, many pension funds and government funds must invest at least a portion of their holdings in a limited set of debt holdings (sometime even further limited by credit rating or in fact by name). Finally, US Treasures can be used as collateral or for hedging as part of certain contracts and/or swap agreements.

.onion crawling was a 20% time project in 2009/2010 (IIRC). I'm sure you could find the announcement if you searched for it. Google does crawl and index.

> Isn't step one President Obama ordering these programs > to be stopped? It's hard to see how he's going to > prosecute anyone for carrying out programs his own > administration either started or allowed to continue.

Yeah, President Obama is the one driving all of this. How can anyone even imagine that he would stop it? And, the next president (probably Hillary) will drive it even harder. 9/11 pushed the US past a point of no return. If you read some recent US military history you can get a well integrated picture of what's really going on. The Office of the President essentially has it's own military, separate from the US Armed Forces and the US Legislature - SOCOM. The President by his hand alone can order SOCOM, in secret, to strike at any time and even to assassinate American citizens. That's an incredible power. It's not the only way the Office of the President has become more powerful in the last decade, though. The number of "signing statements" used by Obama to bypass congress is mind blowing. The only way the power of the Office of the President will be reduced in the future, and things like the NSA domestic surveillance activities stopped, is through a civil war that ends in a new constitution and completely restructured government. Does anyone really think that members of congress aren't being blackmailed with information the domestic surveillance activities produced? Look at the recent monitoring of press phones to see that the capabilities are turned against our representatives. Look to the recent insider trading investigation to see the kinds of things they'd be blackmailed over. They're powerless.

Didn't Assange say in a (secretly?) recorded video where he was talking with Schmidt and another person that while the Americans got trusted root keys from Diginotar, the Chinese hacked Verisign and grabbed their root keys? I'll see if I can find the video.