SAMIT: Stop Using Secure Email
-
I watched this.
Turns out that Protonmail, et. al., are little more than ordinary email plus 80's-style BBS's.
Who knew?
-
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25? -
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?Not on any business class system. And never if you don't want it to. Port 25 supports TLS encryption and systems aren't considered even remotely production ready if they don't accept TLS now for many years. Most systems will allow unencrypted fall back if one of the parties refuses TLS, but either party (or both) have the right to demand it.
If you use a system like Zoho, it notifies you if someone uses unencrypted channels to send to you so you can do something about it. They give you an alert, much like if you go to a http site instead of https (it's the same basic deal.)
So any reasonable email system... Microsoft, Google, Amazon, Zoho, Proton, etc. all are secure by default. And any you run yourself, Postfix, SendMail, Zimbra, Exchange, are supposed to be unless someone really screwed up their install. And you can always make it forced, so any attempt to communicate without TLS is dropped.
I was actually busy updating TLS certs for a big corporate email system just today
-
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?If you use things like free cPanel email or your ISPs email or have your nephew deploy his own email server without hiring any IT people... it's plausible that someone will screw up the config and leave it unsecured or if you accidentally host your email with scammers or something. That's essentially true with any misconfigured system of any type.
And even when misconfigured, most systems today will enable it by default. You'd have to run something unmaintained for a super long time or really go out of your way to do a bad job to have it come up in a new deployment.
There's no reasonable case where a business (or an individual at home) would not have obvious access to a secure system and defy all reasonable recommendations for many years and demand to be intentionally insecure to make them be in a situation where they don't have security on their own end and only if sending data to an insecure second party would the data be at risk and when that happens, the encrypted channel is moot because the target itself is insecure so it doesn't matter.
-
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?If you use things like free cPanel email or your ISPs email or have your nephew deploy his own email server without hiring any IT people... it's plausible that someone will screw up the config and leave it unsecured or if you accidentally host your email with scammers or something. That's essentially true with any misconfigured system of any type.
And even when misconfigured, most systems today will enable it by default. You'd have to run something unmaintained for a super long time or really go out of your way to do a bad job to have it come up in a new deployment.
There's no reasonable case where a business (or an individual at home) would not have obvious access to a secure system and defy all reasonable recommendations for many years and demand to be intentionally insecure to make them be in a situation where they don't have security on their own end and only if sending data to an insecure second party would the data be at risk and when that happens, the encrypted channel is moot because the target itself is insecure so it doesn't matter.
Yes, even scammers and spammers use TLS nowadays.
The only time we ever receive emails that are not TLS encrypted have been same odd email notifications from ERP or LOB systems. Probably legacy systems.
-
@Pete-S said in SAMIT: Stop Using Secure Email:
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?If you use things like free cPanel email or your ISPs email or have your nephew deploy his own email server without hiring any IT people... it's plausible that someone will screw up the config and leave it unsecured or if you accidentally host your email with scammers or something. That's essentially true with any misconfigured system of any type.
And even when misconfigured, most systems today will enable it by default. You'd have to run something unmaintained for a super long time or really go out of your way to do a bad job to have it come up in a new deployment.
There's no reasonable case where a business (or an individual at home) would not have obvious access to a secure system and defy all reasonable recommendations for many years and demand to be intentionally insecure to make them be in a situation where they don't have security on their own end and only if sending data to an insecure second party would the data be at risk and when that happens, the encrypted channel is moot because the target itself is insecure so it doesn't matter.
Yes, even scammers and spammers use TLS nowadays.
The only time we ever receive emails that are not TLS encrypted have been same odd email notifications from ERP or LOB systems. Probably legacy systems.
oh for sure, the only people we ever see on unencrypted email are senior citizens and doctors these days.
-
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@Pete-S said in SAMIT: Stop Using Secure Email:
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?If you use things like free cPanel email or your ISPs email or have your nephew deploy his own email server without hiring any IT people... it's plausible that someone will screw up the config and leave it unsecured or if you accidentally host your email with scammers or something. That's essentially true with any misconfigured system of any type.
And even when misconfigured, most systems today will enable it by default. You'd have to run something unmaintained for a super long time or really go out of your way to do a bad job to have it come up in a new deployment.
There's no reasonable case where a business (or an individual at home) would not have obvious access to a secure system and defy all reasonable recommendations for many years and demand to be intentionally insecure to make them be in a situation where they don't have security on their own end and only if sending data to an insecure second party would the data be at risk and when that happens, the encrypted channel is moot because the target itself is insecure so it doesn't matter.
Yes, even scammers and spammers use TLS nowadays.
The only time we ever receive emails that are not TLS encrypted have been same odd email notifications from ERP or LOB systems. Probably legacy systems.
oh for sure, the only people we ever see on unencrypted email are senior citizens and doctors these days.
Iād add smaller ISPs too.
-
@scottalanmiller said in SAMIT: Stop Using Secure Email:
but either party (or both) have the right to demand it.
This can be interpreted simply as the client or MTA "requesting" an insecure connection, right?
I see most WHM/cPanel servers configured for SSL/TLS but will always accept non encrypted messages from other MTA servers.
Do you think it is safe (from an undelivered mail perspective) to refuse non-TLS connections from servers too?
-
@Dashrender said in SAMIT: Stop Using Secure Email:
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@Pete-S said in SAMIT: Stop Using Secure Email:
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@JasGot said in SAMIT: Stop Using Secure Email:
@scottalanmiller
For regular e-mail (not "Secure E-Mail"), isn't the message traveling un-encrypted when it is moving MTA to MTA on port 25?If you use things like free cPanel email or your ISPs email or have your nephew deploy his own email server without hiring any IT people... it's plausible that someone will screw up the config and leave it unsecured or if you accidentally host your email with scammers or something. That's essentially true with any misconfigured system of any type.
And even when misconfigured, most systems today will enable it by default. You'd have to run something unmaintained for a super long time or really go out of your way to do a bad job to have it come up in a new deployment.
There's no reasonable case where a business (or an individual at home) would not have obvious access to a secure system and defy all reasonable recommendations for many years and demand to be intentionally insecure to make them be in a situation where they don't have security on their own end and only if sending data to an insecure second party would the data be at risk and when that happens, the encrypted channel is moot because the target itself is insecure so it doesn't matter.
Yes, even scammers and spammers use TLS nowadays.
The only time we ever receive emails that are not TLS encrypted have been same odd email notifications from ERP or LOB systems. Probably legacy systems.
oh for sure, the only people we ever see on unencrypted email are senior citizens and doctors these days.
Iād add smaller ISPs too.
A few, but most small ISPs just use GMail. It's giant ISPs that do nefarious things at scale you have to worry about.
-
@JasGot said in SAMIT: Stop Using Secure Email:
This can be interpreted simply as the client or MTA "requesting" an insecure connection, right?
Yes, or more appropriately, "demanding."
-
@JasGot said in SAMIT: Stop Using Secure Email:
Do you think it is safe (from an undelivered mail perspective) to refuse non-TLS connections from servers too?
It depends on the circumstance. Do you want to do business with anyone or just people with a clue?
As an IT company, we need insecure messages from clueless people because that's who needs to hire us. So accepting insecure messaging is a need of pretty much any marketing or sales team.
But an IT engineering team could be locked down.
But really, if you are in the business of communicating with people who don't have TLS allowed, you have bigger security problems than the email encryption. So I'd want to investigate the entire security picture rather than one minor aspect of it. Insecure email is rarely a big deal, people who are okay requiring insecure email are almost always a big deal.
-
@JasGot said in SAMIT: Stop Using Secure Email:
I see most WHM/cPanel servers configured for SSL/TLS but will always accept non encrypted messages from other MTA servers.
Basically everyone works that way because almost no one wants, by default, to refuse emails from clueless, insecure family members.
-
Also, accepting insecure email is different than allowing your organization to send insecure email.
-
@JaredBusch said in SAMIT: Stop Using Secure Email:
Also, accepting insecure email is different than allowing your organization to send insecure email.
Very true. Accepting things insecurely is better than sending them.
-
@scottalanmiller said in SAMIT: Stop Using Secure Email:
@JaredBusch said in SAMIT: Stop Using Secure Email:
Also, accepting insecure email is different than allowing your organization to send insecure email.
Very true. Accepting things insecurely is better than sending them.
I accept email in any way that it is sent. But all sent email is required to be TLS or it will not send. I have a couple of people that the boss cannot email because of it, as well as one prior customer that is still running an ancient ass GroupWise 6 email server. They email asking for one off support for their routers sometimes.
