email security

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

a viewer

Well-known member
Sep 30, 2020
89
27
Without going off to the rough, I keep wondering about email system security. Not the connection between you and your server (which one can assume a certain amount of security because of ssl), but all the other connections along the way. If I recall correctly, email used to travel through a relay chain. So during those transits, your messages could be vulnerable to spying. Probably not all exim systems are using ssl when relaying mail.

Without talking about s/mime, encrypted messages, etc. how vulnerable are emails between the exit point of the sender (skipping key recorders, network intrusions, etc.) and my receiving it?

Considering all equal, between sending an email and a message (whatsapp, signal, telegraph, etc), I'm been inclined to use messages to send information I don't want thirds party to access easily (if their system is compromised all bets are off, but let's assume they aren't, as if you could nowadays)
 
Email (as defined by RFC 822 https://tools.ietf.org/html/rfc6854 ) has NO security what-so-ever. Other than specific cases where you have email staying within a single system, or you are making your own efforts to protect it (such as PGP/SMIME) you should never assume that a message won't be in the clear between the sender and the receiver. There aren't many relays any more... most sender servers connect directly to the receiver server, but that connection is over an Internet trunk and you can be damn sure that the NSA and other similar governmental agencies are slurping all those messages (even the encrypted ones) for later analysis.
 
I don’t even know where to begin.

Most major mail providers will employ a method called opportunistic TLS, where they advertise support for TLS as an extension (STARTTLS defined in RFC 3207).

Here, Apple's mail service:
Code:
~$ nc mx01.mail.icloud.com 25
220 iCloud SMTP - pv33p00im-smtpin007.me.com 3.4.7 (2007B214-541c992ee771)
EHLO demo
250-pv33p00im-smtpin007.me.com
250-PIPELINING
250-SIZE 28311552
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
QUIT
221 2.0.0 Bye

Nothing prevents a third-party from stripping that header, since it is sent over plain text on the wire. A mail operator can enforce mandatory TLS, but that's extremely optional and rare, and even then, nothing prevents MitM attacks, since certificate validation is also optional.

So, assume that your message is sent in plain text, and make sure you apply proper protection to sensitive information IF YOU MUST send it over email.
 
For a typical e-mail message (no specific act taken to encrypt) I'd also think the message is sitting unencrypted (or unencryptable) on the recipient e-mail system/server. That destination company should be able to read all e-mail messages.
 
Thanks

As bad as I remembered. Most people still assume email is secured :| and insist on using it for sensitive documentation
 
Thanks

As bad as I remembered. Most people still assume email is secured :| and insist on using it for sensitive documentation
When you give sensitive documents to another party, they are beyond your control anyway. Whether you send them encrypted doesn't really matter because you have no control over how they store your documents and if the company may suffer from a breach in the future.

You should always blank everything that isn't necessary and write the receiving company all over it or apply a large watermark. Make sure the document cannot be used anywhere else.
 
Yes, my bank used to send a statement as an "encrypted" email, which was just putting the statement in a PDF, without any sort of encryption. Most now seem to have at least moved to encrypting the PDF, which is much better, though only the one bank went the whole hog and used encryption, with you getting a blob, and having to install Stiata reader to view it. That at least is written to work on both Windows, from XP onward, on a lot of versions of MacOS, and is in Linux repositories as well, or download the appropriate package for use. I assume they also have mobile versions as well.

Email regard it as basically a post card, sent from hand to hand from you to the recipient, and you have zero control over how it is moved. You want security, add an envelope with only an address on the outside, which is basically encryption of sorts.
 
You should always blank everything that isn't necessary and write the receiving company all over it or apply a large watermark. Make sure the document cannot be used anywhere else.
In the absence of something else, having both sender and recipient use something like protonmail.com is important if any semblance of security for email is desired.
 
Does this also apply to a service like ProtonMail? I have been using Gmail since it was invite only, but slowly thinking about migrating away from Gmail.
 
apply to a service like ProtonMail
If a given email stays within a single service then it is not going to be exposed to other mail handling agents and is more secure than an email that is between services. Interoperability between services frequently yields fallback to the least common denominator... which is pure text. (7-bit ASCII for example, which means binary data needs to be encoded to text as well.)
 
Secure mail is hard. As pointed out, there are many ways to skin the cat, almost all of which leave some fir in place. In no particular order:
  • Opportunistic TLS - relaying SMTP servers negotiate to use TLS; this is in place for most big providers and companies and works 99.9% of the time
  • Enforced TLS - as above but will not go down from TLS and will eventually fail to send the message if the TLS connection cannot be established
  • S/MIME - PGP and the like - person-to-person secure with overheads that all parties in the conversation have to get certificates of some kind that each other trusts
There is some security if the mail stays with the same provider - like Protonmail - but then all parties need to be on the same service to converse.

In short, email is not particularly secure (or rather is hard to secure for all parties all of the time). If you need real security then you get inconvenience and lose compatibility (you may not be able to use all devices, for example). If you really need security then use a different communication tool.

FWIW, email passing over the Internet does not typically pass through 43 relaying servers; send an email from gmail to outlook, it will leave Google SMTP servers and relay directly into the MS SMTP servers. So you end up considering whether you trust the provider that you're using (and of course the service that the other parties are using).

Finally, once the email can be displayed, you have to trust the endpoint the other parties are using plus what they might do with the email itself. Print, forward, store somewhere less secure.

So the story is once your message is converted to bits, you fundamentally no longer have control of those bits.
 
I agree with danlock - an excellent way to get encrypted messages is from one ProtonMail user to another PM user. If you do this, ProtonMail can read the subject line of the message but not the body. If there is an attachment, they can see the file name of the attachment, but they can not open the file. ProtonMail has free accounts.

A ProtonMail user can send sort-of-almost encrypted messages to anyone, but the sender and recipient have to first agree on a password. The recipient gets a URL and to view the message that URL represents, they need to enter the password.

Pretty sure the same rules apply to Tutanota.
 
A ProtonMail user can send sort-of-almost encrypted messages to anyone, but the sender and recipient have to first agree on a password. The recipient gets a URL and to view the message that URL represents, they need to enter the password.
a classic example of how email security is both hard and inconvenient. All aspects involve trade-offs.

A corporate example of this is Totemo; once again, you have a "fake" inbox on another platform.
 
I'm not endorsing this, but I did play with it when it was first announced. (I got locked out, not sure if their bug or mine, but as I only ever used it as proof of concept testing, I'm not concerned. I don't actually use email much, so I stick to Gmail, mostly, for the anti-spam measures.)

 
that looks interesting but once again, only really secure in their back yard:

Emailing non-Criptext users​

All emails sent to non-Criptext addresses (Eg. Gmail, Yahoo, Outlook) are sent as normal, unencrypted emails.

I am going to try it though :)