Not exactly. With SSL, encrypted communication goes between client and server. In case of this app, encryption is done with user's public keys, no server is involved in encrypting messages. Server role is only in signing public keys to ensure their authenticity. But that alone is bad and insecure practice.

That "Signing public keys to ensure their authenticity" is exactly what (any of the possibly as many as 600) public CA's that your browser and/or OS come pre-configured to "trust".

Who the hell are "Xramp Global CA"? "VRK Gov Root CA"? "UCA Root"? "Trusted Certificate Services"? They're all just random selections from the first page of trusted root certs in this OS X machine's list of System Root keys. Any of them could choose to "authenticate" a public key that claims to be my bank. Apart from the few pinned certificates in Chrome (I think mostly Google certs), I've got no more reason to believe any SSL connection I make is "authenticated" any more than Iranian Gmail users should have had when a DigiNotar root CA cert had signed those rouge Google SSL certs.

That's for communicating with your bank. If you can't trust your legal system for that, then you have much bigger problems.

It also used to "secure" your email communication with Lavabit… And the 8 (alleged) PRISIM participants. From what I read – "trusting the legal system for that" perhaps isn't a particularly prudent idea.

If the government doesn't want to recognize the value of your money, they don't need to snoop on your communications with your bank to do it.

Conversely if you're actually interested in protecting your information, then client-side encryption with self-authenticated keys has always been the only solution.