I predict sometime soon as fragmentation of video services and content continue we will start to see video services changing their systems to prevent providers from screwing with them to gain competitive advantage.
Yet they'll not realize that it is essentially pointless because mobiles don't have a decent resolutions for useful HD, it's just crushed in to such a small screen., 480p is fine for mobiles. Only if you have a >10inch screen would HD make sense to even want.
You should not have ANY one single point of failure.
Agreed.
Only 1 card holder? Single point of failure. More importantly: Only 1 cloud provider? Single point of failure.
Hosting everything on a single planet is also a single point of failure. Drawing a box and labeling something a single point of failure is so much fun.
If you're running that level of cash, and still insist on outsourcing infrastructure, then fucking distribute it. Mirror the infrastructure between AWS, GCloud, and Azure.
Isn't this why people go to overpriced hosted solutions by major providers because they have access to redundancy and DR services they wouldn't be able to pull off themselves? Hey if I check this box all my data gets replicated to some place else hundreds or thousands of miles away.
Is there data available that supports the assumption straddling multiple providers leads to better reliability outcomes or is it just an assumption?
What about costs involved not just in terms of additional dollars owed to hosting providers but also cost of management, increased system complexity and possibility of failure as a result? I've personally witnessed misconfigured backup systems cause disasters.
Even these companies themselves know this. Look up Amazon's DNS providers. Hint, its not JUST AWS, but they outside their own shit too *JUST IN CASE* their servers go offline.
Someone has to watch the watchers. It's all part of making sure the service works without a single point of failure even when armchair engineers are able to draw a box and label something a single point of failure.
The web isn't the web of 25 years ago, and it's plain FUD to bring up Google or "corporations" in general as trying to manipulate us into something that's not good.
Personally I think the fact Google is both in a position to force this by itself and is leveraging that position is a bad thing regardless of intent. In fact I would argument intent is entirely irrelevant. They could have all the best intentions in the world and it still wouldn't justify means.
What worked 25 years ago for a few nerds doesn't work for the bulk of humanity.
I've always found myself mildly amused of the cross section of people who put up websites or bother to learn enough wiki markup to contribute to Wikipedia. It was never just nerds. A surprisingly diverse crowd were willing and able to do these things and do them decades ago when systems were much less available and harder to use than they are today.
I personally believe the Internet is substantially worse off than it was 25 years ago. Power just keep getting more and more aggregated into the hands of fewer and fewer. Users are now being owned enmasse by corporations in ways that previously only illegitimate underground would dare contemplate.
We need something better. If you're not going to offer it, then don't conflate the efforts of many organizations as "Google's will" to make it sound evil.
What does it matter whether someone is able or willing to offer something better? How does their ability affect the merits of topic at hand?
But my sympathy has limits. In this day and age it's irresponsible to leave old, unmaintained stuff on the web.
These days the entire net is constantly being scanned for stuff like buggy SSH versions, exploitable wordpress instances and a myriad other bugs. If you're leaving your old stuff completely unmaintained it's pretty much guaranteed that somebody will break into that box sooner or later, and then use it for some nefarious purpose.
Actually using wordpress at all is irresponsible.
The age where you could just set up a box in the closet, use it to serve a page about your cat, and then forget about it is sadly long over. These days if you're not paying attention, installing updates and keeping up with what's going on with it you'll end up serving trojans, sending spam, or being a member of a botnet, if not something worse.
I bet if you serve static html pages and only allow http access from the net that box in the closet will never get hacked.
What has changed for the worse is proliferation of complex systems designed by idiots for idiots. Wordpress is a great example of this. CVE databases littered with SQLi and XSS bug as far as the eye can see year after agonizing year since turn of the century. There are exactly zero excuses for the presence of these classes of vulnerabilities.
If you don't have the time to go to letsencrypt.org, get a free cert, and tell Apache to use it, you shouldn't be running that server.
Yea bullshit. The reality is closer to if you are using Wordpress you shouldn't have a website.
1. Privacy, so that ISP's and other companies don't get to record which old files you access and when
This is bullshit. It's been proven to be bullshit. Creeps in the wires know where you are going. They see IP headers, SNI indications, public key identities and TLS session keys. They know size, timing and length of transfers.
This is sufficient information to deduce exactly what you are doing on a publically accessible website with high degree of accuracy regardless of encryption.
Last time I went shopping for a mouse many years ago ended up with comfort mouse 6000 (S7J-00010). It's the best mouse I've owned so far. Only problem with it using scroll wheel as middle button is virtually impossible without having click register as a scroll.
Apparently this new IntelliMouse suffers from losing track of where it is when moved rapidly. Reviews so far gamers seem to hate it.
It's like they don't even bother testing hardware before release. These are all things that should have been easily identified and resolved prior to releasing product.
I had a stockpile of old IntelliMouses for years because eventually the left and or right clickers would always break. The rough plastic material also really sucks. It always accumulated gunk that was impossible to remove. Shiny plastic like the comfort mouse is best because gunk slides right off and mouse always looks brand new.
There seems to be a huge gap when it comes to wired mice.
You either end up with some tiny cheap ambidextrous POS made by the lowest bidder, some crazy "ergonomic" BS or ridiculous "gamer" machination that looks like it came out of a transformers movie. Almost got a razer death mouse until I found out driver calls home and requires an Internet connection to work. No chance in hell.
Companies that do nothing but HID like Logitech have all of a single wired USB mouse I would even consider (M500). I don't understand why mice are so screwed up.
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.
SRP-6 is now something like 16 years old. The only excuses in various WGs for not using it last decade were unspecified patent fears from company "L" too lazy to perform an internal search and state a public position. All of that is history now.
Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.
I don't understand the difference. Who creates the public key? How does the peer validate/trust it?
When I hear use public key I think of cipher suites which leverage both the PAKE and RSA et el together in a single TLS handshake. This requires servers to possess a private key and clients to posses a trustworthy public key with a verifiable trust path linking the two.
Honestly, I'm no expert in PAKEs, but a lot of them are built on Diffie-Hellman where this sort of check has been long known as needed depending on the group you're working in and whether its a static or ephemeral exchange. It seems disingenuous to call that a "flaw."
This position makes sense. If a problem can be reasonably avoided and made to work as intended then great.
My perspective is comparative. Dragonfly vs alternatives. For example if there were two competing standards say AES and BES. Both were the same in all known respects except BES was not vulnerable to timing attacks then picking AES wouldn't make much sense even though the "flaw" in AES could be effectively mitigated with blinding.
Some of the skepticism surrounding Dragonfly in practice seems to be more related to concerns with how the security review went down in the CFRG, and some connections to the NSA, than with the protocol itself.
Dragonfly also requires server storage of passwords in a reversible form which is an unnecessary risk. If I steal your password database I can login as your users. Any salting or transform schemes over the top don't alter this basic equation.
With other systems if I steal your password database I can perform offline attack and pose as intended party but I can't login as your users unless my offline brute force campaign bears some fruit.
I never expressed an opinion with regards to severity. What I know is the flaw exists in Dragonfly while other PAKEs have addressed the specific problem.
If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away.
What this essentially says is that if you punt the problem to something else the original problem no longer matters.
This isn't at all useful. The whole point of PAKEs are to securely leverage mutual password knowledge to establish a secure trusted channel not offload trust to something else. If a particular PAKE is incapable of doing what it is intended to do then FFS lets pick one that is.
The utility of non-enterprise WPA3 is that it be beneficial to normal people. Asking people to deploy PKI in order to mitigate flaws in a PAKE is basically telling them to go fuck themselves. It makes the technology worthless to a non-trivial subset of users.
Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.
I don't know what the real world practical implications of the flaw are. If it can be reasonably mitigated that's great. Yet the question in my mind remains. If you are creating something new why not pick an algorithm that doesn't have the flaw in the first place?
Are you daft? We know that passive attacks on WPA/2 exist.
The thread has nothing to do with attacking WPA2. It's all about stupid pointless quibbling over the relative uselessness of "opportunistic encryption".
OP incorrectly believes it's a "big deal".
I think it's better than nothing and worth doing but only if kept quiet and not advertised to the public as a security measure.
How do you propose that the Transport Layer be used to provide security for the Data Link Layer?
TLS is transport agnostic. Just needs something that acts like a byte stream to work. TLS is for example is commonly negotiated over 802.1x/EAPOL which in-turn provides encryption keys to lower layers.
Allow me to present an analogy: Government spies do "full take" surveillance. They just record everything. This is a passive attack and it's thwarted even by
So now I'm supposed to think that stalking is "attacking" or were the goal posts installed in shifting sands? Where do I file a criminal complaint against Google and Microsoft for "attacking" me?
Government spies are pulling everything enmasse from fiber taps of all the tier 1 carriers. They don't give a crap about local Harbucks wifi except to collect MAC addresses and perform trivial flow analysis to deduce your address and what your doing regardless of your use of encryption.
encryption without authentication. You may think that most Wifi attacks worth pulling off are active attacks, but I posit that you only think so because you don't hear much about passive attacks, as they are practically impossible to detect.
I posit invisible fire breathing dragons exist but you don't hear much about them since of course they are invisible.
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something else practical gaining some small toehold (on Android).
Just use EAP-TLS yet rather than or in addition to certs use a PAKE at TLS layer like TLS-SRP. It is drop in compatible with existing RFCs, you just need to write a couple of callbacks to make it work and it will benefit from generic interfaces for other PAKE like ciphers to provide crypto-agility in TLS 1.3 and beyond so your not constantly chasing protocols.
Maybe wrap it in an opportunistic unauthenticated TLS session to gain fast resumption and identity privacy against passive (but not active) attackers, but that still leaves you without an inline password-change mechanism...
The nice thing about TLS-SRP it allows you to do both RSA and SRP so identity doesn't have to be in the clear.
Did some trolling of vendor sites and while most vendors in our orbit of the world don't support RadSec I did find two that do. This is really nice to see and somewhat unexpected. I hope adoption picks up rapidly.
An active attack (e.g. a MITM attack) is detectable.
If active attacks are so detectable why are they allowed to happen? Why are they not "detected"? Did the attacker forget to set evil bit?
A passive attack (e.g. eavesdropping on a WPA2 encrypted connection when you know the PSK) is undetectable.
I think I understand in narrow must be true by construction of argument sense if nothing transmits a signal then a transmitted signal can't be detected. Otherwise in any context with real life import this assertion is most certainly false.
In the real world there must be time and effort expended to prepare attacks. The receiver must have a physical presence and associated resource requirements (power, backhaul or storage). Someone has to transport it into place and possibly remove it.
Generally there will also be some kind of consequence associated with being hacked that can be detected even if no signal is transmitted. For example if everyone at Harbucks who purchased something from "e-bay.com" had their card account wiped out there is still opportunity for detection.
That's an important difference and encryption without authentication makes this difference
Here is where things go off the rails. If you have such magical ability to determine whether a transmitter is associated with a "good" person rather than a "bad" person then why not leverage such ability to prevent bad people from doing something bad in the first place?
At present most WiFi attacks worth pulling off are in fact active attacks and have been such for quite some time. In the era of proliferation of E2E encryption (e.g. https) passive sniffing is not a profitable enterprise. You won't get any passwords or credit card numbers or anything of value by passively sniffing wires because most data is encrypted anyway regardless of whether wireless link is or is not encrypted.
Preventing active and passive attacks is better than only preventing passive attacks, but only preventing passive attacks is better than not preventing any attacks.
Opportunistic encryption is better than nothing yet it also solves nothing and is therefore pointless and not worth mentioning or advertising.
If this is ever sold or advertised to end users as a "security" or "encryption" feature then I would argue that YES opportunistic encryption is actually worse than nothing because misleading indications are being fed to the public and people may assume something is secure when in fact no such assumption is warranted.
What makes enterprise more secure is the fact that the encryption key changes with each user session. So even if someone manages to break your WPA2 Ent. key, they can only get data from that single session
There are two avenues of attack either one is sufficient to completely retroactively defeat session encryption.
The first and most difficult avenue is defeating session keys derived between authenticator and supplicant.
Session keys are derived from the TLS sessions premaster secret + peer randoms. If the authenticator's private key is compromised you can do the exact same shit and compromise all prior sessions for the case where TLS premaster secret was not derived from a forward secure cipher suite. Depending on your environment this may be a much safer bet than you realize given the amount of legacy BS tolerated and lack of visibility and tools to detect these kinds of configuration problems.
next time you sign on you are on a new key and they have to break it all over again
The second approach is defeating the transport of session keys between authenticator and whatever is terminating encryption. This typically means link between RADIUS server and access point.
The only secret information is RADIUS secret everything else is sent in the clear unless the link was protected separately. If I have the encryption key and the encrypted version of it I can now attack the servers secret with impunity offline. If my attack is successful and I successfully compromise the RADIUS secret every damn session that ever used that key I instantly have access to even if the best cipher suite in the world with super forward security was used.
...you ain't been around. Most systems these days authenticate from the controller, not the AP,
so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPsec or a vendor's minor perversion of IPSec,
You're right, I've not been around. I've never seen an environment where any of this has occurred. All I see are APs terminating RADIUS and RADIUS over insecure WAN/LAN and even Internet links.
Also a lot of the controllers support either terminating IPSec generically, or RadSec for RADIUS.
Now I know you are just fucking with me. A lot of nothing currently supports RadSec.
The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
I disagree. With one or a small number of individuals WPA2 provides superior security.
I've never seen a properly configured supplicant in my life.
Basic things like linking cert identity to what your connecting to have been punted to clueless end users. The only reasonable way WPA2-Enterprise works in practice is by pushing configuration to clients in advance.
I've also never seen a secure authenticator in my life. I very much doubt a secure implementation even exists in the field. Encryption keys for the channel between authenticator and AP are literally encrypted with MD5(secret + authvector + salt) XOR key.
Encryption means a third party eavesdropping can't parse the communication.
Encryption without trust is an oxymoron. "Third party" is a rather meaningless concept when you have no earthly clue who the "first party" is in the first place.
There's no requirement that these be linked.
Trust is a core requirement of EVERY secure system with NO EXCEPTIONS.
Encryption without authentication does leave the door open for a man-in-the-middle attack, but it does block passive monitoring.
Who cares? If I can receive a signal I can transmit one just as easily. All WiFi radios are transceivers.
Given proliferation of https the salient threat to end users from unsecured Wi-Fi has always taken the form of ACTIVE adversaries doing a hell of a lot more than just passively listening in.
Opportunistic encryption is better than nothing yet it isn't a solution to any problem. The biggest fear I have is the word "encryption" has a completely different meaning to the general public. When someone uses the phrase. "It's encrypted" what the public hears is "It's secure"... Having no security is better than transmitting a false impression of one. I refuse to believe "encrypted" won't be speciously advertised where no actual security exists.
Personal authentication is less secure, but you don't need anything besides the router.
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
Enterprise authentication is more secure but requires additional infrastructure. E.g., the 802.1X authentication for WPA2 Enterprise requires a RADIUS server or equivalent to authenticate users.
LOL... is this the same ultra secure protocol that encrypts session encryption keys between authenticator and AP with MD5 xor? Give me a break.
Anybody selling that lie needs to understand that ALL cryto based security techniques are temporary, regardless of how well they are envisioned and implemented.
Which is why Wi-Fi Alliance has no business rolling their own. They should use TLS at least to derive session keys if for no other reason than crypto agility.
Slashdot Mirror
Having a VR lens won't improve your screen's resolution.
The point is resolution matters when your smartphone is used in this way. 480 ... 1080.... 2160 ... are all quite noticeable leaps in quality in VR.
480 looks like total crap in VR. Contrary to OPs assertion 480 is far from sufficient.
Why don't they just use a tried and true protocol like HTTPS instead of rolling their own protocol?
This is in fact what Diameter does for security it uses TLS just like HTTPS.
I predict sometime soon as fragmentation of video services and content continue we will start to see video services changing their systems to prevent providers from screwing with them to gain competitive advantage.
Yet they'll not realize that it is essentially pointless because mobiles don't have a decent resolutions for useful HD, it's just crushed in to such a small screen.,
480p is fine for mobiles.
Only if you have a >10inch screen would HD make sense to even want.
Or using VR lens over your smartphone.
You should not have ANY one single point of failure.
Agreed.
Only 1 card holder? Single point of failure.
More importantly: Only 1 cloud provider? Single point of failure.
Hosting everything on a single planet is also a single point of failure. Drawing a box and labeling something a single point of failure is so much fun.
If you're running that level of cash, and still insist on outsourcing infrastructure, then fucking distribute it. Mirror the infrastructure between AWS, GCloud, and Azure.
Isn't this why people go to overpriced hosted solutions by major providers because they have access to redundancy and DR services they wouldn't be able to pull off themselves? Hey if I check this box all my data gets replicated to some place else hundreds or thousands of miles away.
Is there data available that supports the assumption straddling multiple providers leads to better reliability outcomes or is it just an assumption?
What about costs involved not just in terms of additional dollars owed to hosting providers but also cost of management, increased system complexity and possibility of failure as a result? I've personally witnessed misconfigured backup systems cause disasters.
Even these companies themselves know this. Look up Amazon's DNS providers. Hint, its not JUST AWS, but they outside their own shit too *JUST IN CASE* their servers go offline.
Someone has to watch the watchers. It's all part of making sure the service works without a single point of failure even when armchair engineers are able to draw a box and label something a single point of failure.
The web isn't the web of 25 years ago, and it's plain FUD to bring up Google or "corporations" in general as trying to manipulate us into something that's not good.
Personally I think the fact Google is both in a position to force this by itself and is leveraging that position is a bad thing regardless of intent. In fact I would argument intent is entirely irrelevant. They could have all the best intentions in the world and it still wouldn't justify means.
What worked 25 years ago for a few nerds doesn't work for the bulk of humanity.
I've always found myself mildly amused of the cross section of people who put up websites or bother to learn enough wiki markup to contribute to Wikipedia. It was never just nerds. A surprisingly diverse crowd were willing and able to do these things and do them decades ago when systems were much less available and harder to use than they are today.
I personally believe the Internet is substantially worse off than it was 25 years ago. Power just keep getting more and more aggregated into the hands of fewer and fewer. Users are now being owned enmasse by corporations in ways that previously only illegitimate underground would dare contemplate.
We need something better. If you're not going to offer it, then don't conflate the efforts of many organizations as "Google's will" to make it sound evil.
What does it matter whether someone is able or willing to offer something better? How does their ability affect the merits of topic at hand?
But my sympathy has limits. In this day and age it's irresponsible to leave old, unmaintained stuff on the web.
These days the entire net is constantly being scanned for stuff like buggy SSH versions, exploitable wordpress instances and a myriad other bugs. If you're leaving your old stuff completely unmaintained it's pretty much guaranteed that somebody will break into that box sooner or later, and then use it for some nefarious purpose.
Actually using wordpress at all is irresponsible.
The age where you could just set up a box in the closet, use it to serve a page about your cat, and then forget about it is sadly long over. These days if you're not paying attention, installing updates and keeping up with what's going on with it you'll end up serving trojans, sending spam, or being a member of a botnet, if not something worse.
I bet if you serve static html pages and only allow http access from the net that box in the closet will never get hacked.
What has changed for the worse is proliferation of complex systems designed by idiots for idiots. Wordpress is a great example of this. CVE databases littered with SQLi and XSS bug as far as the eye can see year after agonizing year since turn of the century. There are exactly zero excuses for the presence of these classes of vulnerabilities.
If you don't have the time to go to letsencrypt.org, get a free cert, and tell Apache to use it, you shouldn't be running that server.
Yea bullshit. The reality is closer to if you are using Wordpress you shouldn't have a website.
1. Privacy, so that ISP's and other companies don't get to record which old files you access and when
This is bullshit. It's been proven to be bullshit. Creeps in the wires know where you are going. They see IP headers, SNI indications, public key identities and TLS session keys. They know size, timing and length of transfers.
This is sufficient information to deduce exactly what you are doing on a publically accessible website with high degree of accuracy regardless of encryption.
Last time I went shopping for a mouse many years ago ended up with comfort mouse 6000 (S7J-00010). It's the best mouse I've owned so far. Only problem with it using scroll wheel as middle button is virtually impossible without having click register as a scroll.
Apparently this new IntelliMouse suffers from losing track of where it is when moved rapidly. Reviews so far gamers seem to hate it.
It's like they don't even bother testing hardware before release. These are all things that should have been easily identified and resolved prior to releasing product.
I had a stockpile of old IntelliMouses for years because eventually the left and or right clickers would always break. The rough plastic material also really sucks. It always accumulated gunk that was impossible to remove. Shiny plastic like the comfort mouse is best because gunk slides right off and mouse always looks brand new.
There seems to be a huge gap when it comes to wired mice.
You either end up with some tiny cheap ambidextrous POS made by the lowest bidder, some crazy "ergonomic" BS or ridiculous "gamer" machination that looks like it came out of a transformers movie. Almost got a razer death mouse until I found out driver calls home and requires an Internet connection to work. No chance in hell.
Companies that do nothing but HID like Logitech have all of a single wired USB mouse I would even consider (M500). I don't understand why mice are so screwed up.
They better get it fixed soon or the backlog of stalker "telemetry" being queued up for delivery will lead to the congestive collapse of the Internet.
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.
SRP-6 is now something like 16 years old. The only excuses in various WGs for not using it last decade were unspecified patent fears from company "L" too lazy to perform an internal search and state a public position. All of that is history now.
Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.
I don't understand the difference. Who creates the public key? How does the peer validate/trust it?
When I hear use public key I think of cipher suites which leverage both the PAKE and RSA et el together in a single TLS handshake. This requires servers to possess a private key and clients to posses a trustworthy public key with a verifiable trust path linking the two.
Honestly, I'm no expert in PAKEs, but a lot of them are built on Diffie-Hellman where this sort of check has been long known as needed depending on the group you're working in and whether its a static or ephemeral exchange. It seems disingenuous to call that a "flaw."
This position makes sense. If a problem can be reasonably avoided and made to work as intended then great.
My perspective is comparative. Dragonfly vs alternatives. For example if there were two competing standards say AES and BES. Both were the same in all known respects except BES was not vulnerable to timing attacks then picking AES wouldn't make much sense even though the "flaw" in AES could be effectively mitigated with blinding.
Some of the skepticism surrounding Dragonfly in practice seems to be more related to concerns with how the security review went down in the CFRG, and some connections to the NSA, than with the protocol itself.
Dragonfly also requires server storage of passwords in a reversible form which is an unnecessary risk. If I steal your password database I can login as your users. Any salting or transform schemes over the top don't alter this basic equation.
With other systems if I steal your password database I can perform offline attack and pose as intended party but I can't login as your users unless my offline brute force campaign bears some fruit.
I think you're greatly exaggerating the problems.
I never expressed an opinion with regards to severity. What I know is the flaw exists in Dragonfly while other PAKEs have addressed the specific problem.
If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away.
What this essentially says is that if you punt the problem to something else the original problem no longer matters.
This isn't at all useful. The whole point of PAKEs are to securely leverage mutual password knowledge to establish a secure trusted channel not offload trust to something else. If a particular PAKE is incapable of doing what it is intended to do then FFS lets pick one that is.
The utility of non-enterprise WPA3 is that it be beneficial to normal people. Asking people to deploy PKI in order to mitigate flaws in a PAKE is basically telling them to go fuck themselves. It makes the technology worthless to a non-trivial subset of users.
Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.
I don't know what the real world practical implications of the flaw are. If it can be reasonably mitigated that's great. Yet the question in my mind remains. If you are creating something new why not pick an algorithm that doesn't have the flaw in the first place?
Are you daft? We know that passive attacks on WPA/2 exist.
The thread has nothing to do with attacking WPA2. It's all about stupid pointless quibbling over the relative uselessness of "opportunistic encryption".
OP incorrectly believes it's a "big deal".
I think it's better than nothing and worth doing but only if kept quiet and not advertised to the public as a security measure.
How do you propose that the Transport Layer be used to provide security for the Data Link Layer?
TLS is transport agnostic. Just needs something that acts like a byte stream to work. TLS is for example is commonly negotiated over 802.1x/EAPOL which in-turn provides encryption keys to lower layers.
Allow me to present an analogy: Government spies do "full take" surveillance. They just record everything. This is a passive attack and it's thwarted even by
So now I'm supposed to think that stalking is "attacking" or were the goal posts installed in shifting sands? Where do I file a criminal complaint against Google and Microsoft for "attacking" me?
Government spies are pulling everything enmasse from fiber taps of all the tier 1 carriers. They don't give a crap about local Harbucks wifi except to collect MAC addresses and perform trivial flow analysis to deduce your address and what your doing regardless of your use of encryption.
encryption without authentication. You may think that most Wifi attacks worth pulling off are active attacks, but I posit that you only think so because you don't hear much about passive attacks, as they are practically impossible to detect.
I posit invisible fire breathing dragons exist but you don't hear much about them since of course they are invisible.
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something
else practical gaining some small toehold (on Android).
EAP-PWD = Dragonfly = Flawed = Fixed protocol = Mistake.
Just use EAP-TLS yet rather than or in addition to certs use a PAKE at TLS layer like TLS-SRP. It is drop in compatible with existing RFCs, you just need to write a couple of callbacks to make it work and it will benefit from generic interfaces for other PAKE like ciphers to provide crypto-agility in TLS 1.3 and beyond so your not constantly chasing protocols.
Maybe wrap it in an opportunistic unauthenticated TLS session to gain fast resumption and identity privacy against passive (but not active) attackers, but that still leaves you without an inline password-change mechanism...
The nice thing about TLS-SRP it allows you to do both RSA and SRP so identity doesn't have to be in the clear.
I guess HPE-Aruba counts as a lot of nothing?
Did some trolling of vendor sites and while most vendors in our orbit of the world don't support RadSec I did find two that do. This is really nice to see and somewhat unexpected. I hope adoption picks up rapidly.
An active attack (e.g. a MITM attack) is detectable.
If active attacks are so detectable why are they allowed to happen? Why are they not "detected"? Did the attacker forget to set evil bit?
A passive attack (e.g. eavesdropping on a WPA2 encrypted connection when you know the PSK) is undetectable.
I think I understand in narrow must be true by construction of argument sense if nothing transmits a signal then a transmitted signal can't be detected. Otherwise in any context with real life import this assertion is most certainly false.
In the real world there must be time and effort expended to prepare attacks. The receiver must have a physical presence and associated resource requirements (power, backhaul or storage). Someone has to transport it into place and possibly remove it.
Generally there will also be some kind of consequence associated with being hacked that can be detected even if no signal is transmitted. For example if everyone at Harbucks who purchased something from "e-bay.com" had their card account wiped out there is still opportunity for detection.
That's an important difference and encryption without authentication makes this difference
Here is where things go off the rails. If you have such magical ability to determine whether a transmitter is associated with a "good" person rather than a "bad" person then why not leverage such ability to prevent bad people from doing something bad in the first place?
At present most WiFi attacks worth pulling off are in fact active attacks and have been such for quite some time. In the era of proliferation of E2E encryption (e.g. https) passive sniffing is not a profitable enterprise. You won't get any passwords or credit card numbers or anything of value by passively sniffing wires because most data is encrypted anyway regardless of whether wireless link is or is not encrypted.
Preventing active and passive attacks is better than only preventing passive attacks, but only preventing passive attacks is better than not preventing any attacks.
Opportunistic encryption is better than nothing yet it also solves nothing and is therefore pointless and not worth mentioning or advertising.
If this is ever sold or advertised to end users as a "security" or "encryption" feature then I would argue that YES opportunistic encryption is actually worse than nothing because misleading indications are being fed to the public and people may assume something is secure when in fact no such assumption is warranted.
What makes enterprise more secure is the fact that the encryption key changes with each user session. So even if someone manages to break your WPA2 Ent. key, they can only get data from that single session
There are two avenues of attack either one is sufficient to completely retroactively defeat session encryption.
The first and most difficult avenue is defeating session keys derived between authenticator and supplicant.
Session keys are derived from the TLS sessions premaster secret + peer randoms. If the authenticator's private key is compromised you can do the exact same shit and compromise all prior sessions for the case where TLS premaster secret was not derived from a forward secure cipher suite. Depending on your environment this may be a much safer bet than you realize given the amount of legacy BS tolerated and lack of visibility and tools to detect these kinds of configuration problems.
next time you sign on you are on a new key and they have to break it all over again
The second approach is defeating the transport of session keys between authenticator and whatever is terminating encryption. This typically means link between RADIUS server and access point.
The only secret information is RADIUS secret everything else is sent in the clear unless the link was protected separately. If I have the encryption key and the encrypted version of it I can now attack the servers secret with impunity offline. If my attack is successful and I successfully compromise the RADIUS secret every damn session that ever used that key I instantly have access to even if the best cipher suite in the world with super forward security was used.
...you ain't been around. Most systems these days authenticate from the controller, not the AP,
so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPsec or a vendor's minor perversion of IPSec,
You're right, I've not been around. I've never seen an environment where any of this has occurred. All I see are APs terminating RADIUS and RADIUS over insecure WAN/LAN and even Internet links.
Also a lot of the controllers support either terminating IPSec generically,
or RadSec for RADIUS.
Now I know you are just fucking with me. A lot of nothing currently supports RadSec.
The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
I disagree. With one or a small number of individuals WPA2 provides superior security.
I've never seen a properly configured supplicant in my life.
Basic things like linking cert identity to what your connecting to have been punted to clueless end users. The only reasonable way WPA2-Enterprise works in practice is by pushing configuration to clients in advance.
I've also never seen a secure authenticator in my life. I very much doubt a secure implementation even exists in the field. Encryption keys for the channel between authenticator and AP are literally encrypted with MD5(secret + authvector + salt) XOR key.
No, it's not.
Yes it is.
Encryption means a third party eavesdropping can't parse the communication.
Encryption without trust is an oxymoron. "Third party" is a rather meaningless concept when you have no earthly clue who the "first party" is in the first place.
There's no requirement that these be linked.
Trust is a core requirement of EVERY secure system with NO EXCEPTIONS.
Encryption without authentication does leave the door open for a man-in-the-middle attack, but it does block passive monitoring.
Who cares? If I can receive a signal I can transmit one just as easily. All WiFi radios are transceivers.
Given proliferation of https the salient threat to end users from unsecured Wi-Fi has always taken the form of ACTIVE adversaries doing a hell of a lot more than just passively listening in.
Opportunistic encryption is better than nothing yet it isn't a solution to any problem. The biggest fear I have is the word "encryption" has a completely different meaning to the general public. When someone uses the phrase. "It's encrypted" what the public hears is "It's secure"... Having no security is better than transmitting a false impression of one. I refuse to believe "encrypted" won't be speciously advertised where no actual security exists.
Personal authentication is less secure, but you don't need anything besides the router.
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
Enterprise authentication is more secure but requires additional infrastructure. E.g., the 802.1X authentication for WPA2 Enterprise requires a RADIUS server or equivalent to authenticate users.
LOL... is this the same ultra secure protocol that encrypts session encryption keys between authenticator and AP with MD5 xor? Give me a break.
However, the big deal here is the opportunistic encryption that will encrypt connections that don't require authentication. That's a big deal.
That's an oxymoron.
Anybody selling that lie needs to understand that ALL cryto based security techniques are temporary, regardless of how well they are envisioned and implemented.
Which is why Wi-Fi Alliance has no business rolling their own. They should use TLS at least to derive session keys if for no other reason than crypto agility.