[HN Gopher] Skiff: Various Privacy Failures
___________________________________________________________________
Skiff: Various Privacy Failures
Author : uselpa
Score : 34 points
Date : 2024-01-14 19:40 UTC (3 hours ago)
(HTM) web link (www.grepular.com)
(TXT) w3m dump (www.grepular.com)
| crimbles wrote:
| Interesting read. I will point out that having seen _" security
| audits"_ done by top tier well known security companies, they
| aren't worth the paper they are written on. They are selling you
| a pen test script run, the output of which is farted into a
| document for the least amount of time they can expend on it.
|
| If you want security, you have to do it in house with competent
| people who understand your business domain. So when I see people
| with regular pen tests I know they don't really give a shit
| because they are doing minimal ass coverage.
| mratsim wrote:
| Disagree, their reputation is tied to their audit quality.
|
| But I'm pretty sure in this case the scope was bad. Like they
| coukd have had audits on "Do I use OpenSSL well?" and then
| misrepresent that all their privacy claims were audited.
|
| Now it seems like Skiff conveniently didn't allow Trail of Bits
| to publish their reports, they are usually here:
| https://github.com/trailofbits/publications/tree/master/revi...
|
| Disclaimer, I have used Trail of Bits service in the past (and
| 2 other auditors for an security campaign on a blockchain,
| cryptography + networking product).
| jitl wrote:
| Really? That's not my experience. I'm not denying companies are
| out there basically selling a rubber stamp like you say, but
| I've worked with sharp folks from Matasano and NCC Group who
| would go deep, learn from eng about system but also do blind
| red teaming, do physical pen tests etc. I think you'll probably
| get what you pay for and get good results if you put in good
| effort working with them.
|
| I can't speak to Cure53 but I feel like I've seen that name on
| a few failed cryptocurrency thingies.
| crimbles wrote:
| I was actually including NCC in that one...
| lcof wrote:
| Great read, I have seen this myself in the last 4-5 years with
| services surfing on the privacy wave - I mean, not just email,
| but also cloud drive. My conclusion, even regarding established
| privacy-focused email providers, is that it's not worth the
| hassle, really. I use trusted and reliable email providers
| (according to me), and I just don't use email for anything
| sensitive. That's just right for me.
|
| I know some people do need more privacy and/or security. But a
| lot of people think they need the same but really, they don't.
| cedws wrote:
| I see Skiff also advertises itself as "end-to-end" encrypted.
| This is the same misleading advertising as ProtonMail is guilty
| of. Traditional email _cannot_ be E2E encrypted because of
| protocol limitations. You _can_ technically achieve E2E
| encryption if using PGP, but if the private keys are not in your
| control then it is effectively pointless.
|
| ProtonMail can only guarantee E2E encryption without PGP if you
| are sending email to another ProtonMail user. I don't know if
| Skiff also offers this special kind of encryption. Either way,
| they should be more upfront about the level of privacy they can
| offer.
|
| I had a read of Skiff's page on E2EE. It is very carefully worded
| and, from a skim read, is not upfront about the fact that un-
| PGP'd email sent and received through Skiff can be read by Skiff.
|
| https://skiff.com/blog/end-to-end-encryption-email
|
| Oh, one more thing. Skiff's SMTP server (inbound-smtp.skiff.com)
| is running on AWS in the United States which means it will be
| beholden to US warrants. Skiff does not have a warrant canary.
| Getting big Crypto AG vibes from this.
| mweidner wrote:
| The product page is clearer (https://skiff.com/mail):
|
| > All emails between Skiff users are end-to-end encrypted,
| including both subject and contents. External mail is encrypted
| with your keys on receipt, keeping it private.
| forwardemail wrote:
| Forward Email team here (https://forwardemail.net), we have a
| write-up and comparison @
| https://forwardemail.net/en/blog/docs/best-quantum-safe-encr...
|
| We've considered adding a E2EE comparison column as well (with
| the issues such @ http://jfloren.net/b/2023/7/7/0 highlighted).
|
| Privacy Guides Discussion @
| https://discuss.privacyguides.net/t/forward-email-email-prov...
|
| Unlike Skiff, Proton, and Tuta... we're _actually_ 100% open-
| source. Those providers that advertise as open-source really only
| open-source the front-end, when the back-end is the most
| sensitive part of an email service.
| cedws wrote:
| This is really nice, but the blog does not address the weakest
| link in the chain: what if you receive a warrant from the US
| government? The SMTP server would be able to collect
| inbound/outbound emails in plaintext.
| forwardemail wrote:
| That is not true. You can upload a PGP key and all your email
| written to SQLite (IMAP/POP3) will be stored with your PGP
| key. Not plain text. SMTP is for outbound, IMAP/POP3 is for
| inbound.
|
| https://forwardemail.net/en/faq#do-you-support-
| openpgpmime-e...
| forwardemail wrote:
| Here is the actual code in the back-end where we use your
| PGP public key:
|
| Source code for PGP encryption for storage when you're
| connected (we only use your password in-memory, and never
| write it to disk on our side) @ https://github.com/forwarde
| mail/forwardemail.net/blob/562a52...
|
| Outbound email automatically checks for PGP key in case you
| didn't include the recipients (we use WKD): https://github.
| com/forwardemail/forwardemail.net/blob/562a52...
|
| Your individual mailbox is a SQLite database file and is
| encrypted using ChaCha20-Poly1305 as well (using your
| password, which only you have access to; we only use it in-
| memory and don't write it to disk).
| cedws wrote:
| Right, but inbound emails over POP/IMAP will be TLS
| encrypted. You're saying emails are encrypted at rest, but
| they cannot be encrypted in-flight because it's
| forwardemail that holds the TLS private key.
| forwardemail wrote:
| @cedws I think one of us might be confused with the context
| here (?) TLS is just a form of encryption to establish socket
| connections. Please thoroughly read through our article and
| our source code.
|
| A PGP encrypted email doesn't get "decrypted" when it's being
| transferred. That's the whole purpose of PGP encryption, to
| encrypt it before it even gets transferred or stored, which
| is what we do. If you set up a PGP key, use WKD, then your
| emails will be stored as encrypted (not only is your database
| encrypted with your password, but the emails themselves can
| be PGP encrypted this way), and any sender attempting to send
| to you will automatically have their message PGP encrypted to
| you, if it is not already (in case their mail client doesn't
| use WKD).
| cedws wrote:
| I think there is a miscommunication. I am not talking about
| PGP encrypted emails - sure, those can be decrypted client
| side. Plaintext emails, as the majority of emails are, will
| be received by your server in plaintext, minus transport
| encryption. How can you guarantee those will not be
| intercepted by authorities?
| forwardemail wrote:
| We use MTA-STS (for inbound AND outbound) with our mode
| set to enforce[1], to require senders to communicate with
| us only using TLS encrypted sockets. There is no legal
| precedence currently requiring software services to
| implement backdoors.
|
| [1]: https://github.com/forwardemail/mta-
| sts.forwardemail.net/blo...
| captainmisery wrote:
| Isn't this just advertising your own company?
___________________________________________________________________
(page generated 2024-01-14 23:00 UTC)