Let's hope it's as good as the old ones... Literally the only Microsoft product I use is an old IntelliMouse Explorer 3.0 a friend of mine (hardcore gamer at that time, so it had already received a lot of abuse) gave me once the 4.0 or whatever came out. That was around 2004; I use it a lot, every day, and apart from replacing the micro switches once after they got bouncy; it's still going strong. Built like a tank, although my fingers have long since worked through the surface coating.
Anyway, given the extreme quality of this good old device, I conclude all Microsoft really had to do with it, is slapping their logo on it (fortunately 14 years of hand sweat has removed that, too).
Plus this is hop-to-hop, you only get to control whether or not to talk to the first hop, after than all bets are off. Let's hope all MTAs in the chain are configured the same way?
So what's the difference between unconditional STARTTLS and SMTPS, other than the former opening up a brief opportunity for a MITM to mess with the connection?
Except that currently, with completely clear-text SMTP transactions, surveillance departments can tap glass and do a wholesale capture of all e-mail traffic over a network hop.
If, however, everyone starts using STARTTLS then the three-letter agencies have to start expending resources to MITM all those various connections. This is much more difficult than simply slurping up bits.
Yes, good point.
The choice is not: 0% security for everyone (plain SMTP) or 100% security for everyone (S/MIME, PGP). Opportunistic encryption is on the sliding scale of giving many people 10/20/40/80/whatever-percent security, all of which is better than 0.
Sure. But keep in mind this is just an EFF recommendation, as far as I understand it. So in and by itself, it doesn't make anybody enable anything. Since this is still dependent on admins (and MUA developers) taking action, they might as well have recommended to go for unconditional SMTPS instead of STARTTLS.
Re your follow up comment, I fail to see how "You have to use STARTTLS with this MTA" is any different (except in that it still allows a MITM to briefly mess with the connection) from SMTPS...
Perfect is the enemy of good (enough).
The problem is that "good enough" isn't necessarily good enough, because the people who define what's good enough may be mistaken.
While this isn't far-fetched, at least it would require the client or MTA to ignore a failed TLS handshake. With certificate pinning, it's about as good (or bad) as what SSH does (learning a host key on first use, later complaining if it changes)
STARTTLS means upgrading an existing plaintext connection to TLS. Mail servers announce (upon EHLO) what features they support, "starttls" can be one of those. When no "starttls" is advertised, the client will not upgrade and keep using the plaintext connection.
Now, connection security only matters if someone has the ability to listen in to the connection. If someone can listen in, they likely can modify the traffic as well. So here's how to break STARTTLS: Remove the 'starttls' capability from the MTA's EHLO response. Done.
The correct solution would be to unconditionally run SMTP-over-TLS (SMTPS) on a dedicated-for-that port (as is already common practice) and remove the plaintext listener if feasible.
To repurpose a quote about OCSP: "STARTTLS is like a seat belt that always works, except when you're having an accident."
The real fail is that the system seems so complex that there was no feasible way for an admin to work out the root cause in a timely manner. Kind of like the feeling I get when troubleshooting service startup issues on systems that run systemd, but oh well.
Well if nothing else, at least as of Meltdown the guest could dump the hosts memory, which should make it hell of a lot less difficult to gain access to the host (not necessarily from within the container)
Better not try to explain something you don't really understand in the first place, I guess.
FWIW you're apparently conflating Unicode and UTF-16 (i.e. your Windows background is showing). The rest of the world tends to use UTF-8, which is a superset of ASCII (which is a 7 bit code BTW), and represents unicode code points using 1-6 bytes.
Ok, after reading that information, I conclude that since a Nullset is a subset of |R, it cannot be "no set at all", since "no set at all" (unlike the empty set) cannot be a subset of anything because it isn't a set to begin with.
The "Null set" is therefore irrelevant for the matter discussed.
Slashdot Mirror
I just ask for their firstborn.
On an unrelated note, is anybody interested in adopting a bunch of small children?
Let's hope it's as good as the old ones... Literally the only Microsoft product I use is an old IntelliMouse Explorer 3.0 a friend of mine (hardcore gamer at that time, so it had already received a lot of abuse) gave me once the 4.0 or whatever came out. That was around 2004; I use it a lot, every day, and apart from replacing the micro switches once after they got bouncy; it's still going strong. Built like a tank, although my fingers have long since worked through the surface coating.
Anyway, given the extreme quality of this good old device, I conclude all Microsoft really had to do with it, is slapping their logo on it (fortunately 14 years of hand sweat has removed that, too).
+1, Troll
Pretty sure it executed a couple HCF instructions as well.
Ok, but Joe Sixpack doesn't.
Plus this is hop-to-hop, you only get to control whether or not to talk to the first hop, after than all bets are off. Let's hope all MTAs in the chain are configured the same way?
So what's the difference between unconditional STARTTLS and SMTPS, other than the former opening up a brief opportunity for a MITM to mess with the connection?
Except that currently, with completely clear-text SMTP transactions, surveillance departments can tap glass and do a wholesale capture of all e-mail traffic over a network hop.
If, however, everyone starts using STARTTLS then the three-letter agencies have to start expending resources to MITM all those various connections. This is much more difficult than simply slurping up bits.
Yes, good point.
The choice is not: 0% security for everyone (plain SMTP) or 100% security for everyone (S/MIME, PGP). Opportunistic encryption is on the sliding scale of giving many people 10/20/40/80/whatever-percent security, all of which is better than 0.
Sure. But keep in mind this is just an EFF recommendation, as far as I understand it. So in and by itself, it doesn't make anybody enable anything. Since this is still dependent on admins (and MUA developers) taking action, they might as well have recommended to go for unconditional SMTPS instead of STARTTLS.
Re your follow up comment, I fail to see how "You have to use STARTTLS with this MTA" is any different (except in that it still allows a MITM to briefly mess with the connection) from SMTPS...
Perfect is the enemy of good (enough).
The problem is that "good enough" isn't necessarily good enough, because the people who define what's good enough may be mistaken.
While this isn't far-fetched, at least it would require the client or MTA to ignore a failed TLS handshake. With certificate pinning, it's about as good (or bad) as what SSH does (learning a host key on first use, later complaining if it changes)
STARTTLS means upgrading an existing plaintext connection to TLS. Mail servers announce (upon EHLO) what features they support, "starttls" can be one of those. When no "starttls" is advertised, the client will not upgrade and keep using the plaintext connection.
Now, connection security only matters if someone has the ability to listen in to the connection. If someone can listen in, they likely can modify the traffic as well. So here's how to break STARTTLS: Remove the 'starttls' capability from the MTA's EHLO response. Done.
The correct solution would be to unconditionally run SMTP-over-TLS (SMTPS) on a dedicated-for-that port (as is already common practice) and remove the plaintext listener if feasible.
To repurpose a quote about OCSP: "STARTTLS is like a seat belt that always works, except when you're having an accident."
Yes, but then again this was a multi day process that no human could stop, or even work out the root cause for, despite knowing it's wrong.
So AI to arrive within the next two years? That's a pretty tight schedule but I like your optimism.
The real fail is that the system seems so complex that there was no feasible way for an admin to work out the root cause in a timely manner. Kind of like the feeling I get when troubleshooting service startup issues on systems that run systemd, but oh well.
Sounds like a Windows IT, or possibly a systemd based one.
Said the guy impersonating AC
Well if nothing else, at least as of Meltdown the guest could dump the hosts memory, which should make it hell of a lot less difficult to gain access to the host (not necessarily from within the container)
Indeed, even Hitler agrees with that
Better not try to explain something you don't really understand in the first place, I guess.
FWIW you're apparently conflating Unicode and UTF-16 (i.e. your Windows background is showing). The rest of the world tends to use UTF-8, which is a superset of ASCII (which is a 7 bit code BTW), and represents unicode code points using 1-6 bytes.
Thanks, that was exactly the point I tried to make :). Agnostic all the way.
Yeah around that time, memory efficient programming basically became extinct. The resources are there, so hell let's use them all.
This might be repeating now, but on a much worse scale.
Thank you for including the "/s", otherwise we'd have had no chance at identifying the sarcasm.
Yeah have fun getting rid of all that heat in a laptop-sized "monster workstation"
Being that Unicode data for hello world uses two bytes for character in generals makes strings 50% inefficient.
Wut
Ok, after reading that information, I conclude that since a Nullset is a subset of |R, it cannot be "no set at all", since "no set at all" (unlike the empty set) cannot be a subset of anything because it isn't a set to begin with.
The "Null set" is therefore irrelevant for the matter discussed.
"I don't know" is not atheism, though.
A Null set isn't necessarily empty, so I have no idea what your point is.