On Wed, Aug 3, 2022 at 10:07 AM Grant Taylor via mailop <mailop@mailop.org> wrote:
> On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote: > > It's a pretty big and well respected security practice to consider plain > > text to be more secure than insecure SSL for one reason: A plain text > > connection isn't logged or reported as a secure connection. > > What‽‽‽ > > Please elaborate. Please point to more documentation related to this > respected security practice. > > > Both being insecure, only one of the two involves your server > > negotiating and reporting to the third party that you are accepting > > it over a secure connection. Which is basically a lie. Plain isn't > > a lie, and that's worth something. > I don't see how considering "not the best security" as more secure than > "no security" is a lie in any way, shape, or form. > > I feel like this is a case of anything less than perfect is not good > enough and thus a waste of time. -- I often see such sentiments > causing people to abandon give up on any from of security and continuing > without any security at all. > > If you must divulge your SSN over the phone (for reasons) do you just > blurt it out at normal volume indifferent to who is around? Or do you > walk to a secluded corner of the room and cup your hand around the mouth > piece? Even questionable security is better than no security in many > cases. > Everything in security depends on your threat model. If the threat model is people who can tap the phone, then it doesn't matter your volume or location when you speak. For the average user, the threat model may be someone overhearing you by chance, and so any encryption is an improvement. For some users, the threat model is someone who can break lower encryption or maybe even force the servers to negotiate a worse encryption level that they can break. Fallback to plain text is the Achilles heel, of course... but some systems have policies requiring encryption... of course, they could just require encryption that meets a certain level as well... (having just had to plumb the tls version of a web request through a wide variety of services to enforce this requirement on a per-user basis, painfully aware...) There are also various certification requirements which have rules about which ssl versions you allow, if you want government contracts or some types of financial ones. They're often couched in ways that make them seem specific to http services, but applying them to other services may depend on your auditor or implementor. Anyways, I'm surprised to see that Google still allows 1.0 and 1.1, I remember disabling support for SSLv2/3 years ago, but I guess the numbers here are still high and they haven't had enough push for it yet. I wouldn't be surprised if the require tls policy has a version limit on it since almost any customer that needs a require tls policy would also need to restrict it to 1.2+, but I didn't look that hard at it. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
