|
hobbesmaster posted:So there’s no difference between using admin/admin as credentials and negotiating a tls1.1 session with TLS_RSA_WITH_AES_256_CBC_SHA?
|
#
?
Oct 12, 2017 00:46
|
|
|
|
| # ? May 12, 2024 20:46 |
|
|
anthonypants posted:Can you tell that there's a difference between that, and saying saying, "b-but IoT devices do it..." Also, guarantee it's probably an ancient version of OpenSSL and has defaults enabled for it. So yeah, you can probably open a door large enough for a truck on that IoT device.
|
|
#
?
Oct 12, 2017 03:11
|
|
|
anthonypants posted:Can you tell that there's a difference between that, and saying saying, "b-but IoT devices do it..." ....so is tls 1.1 weak at the moment or not? Some ciphers certainly are. Proteus Jones posted:Also, guarantee it's probably an ancient version of OpenSSL and has defaults enabled for it. I said radio modules. Those do not run linux.
|
|
#
?
Oct 12, 2017 04:54
|
|
|
hobbesmaster posted:....so is tls 1.1 weak at the moment or not? Some ciphers certainly are.
|
|
#
?
Oct 12, 2017 08:20
|
|
|
hobbesmaster posted:....so is tls 1.1 weak at the moment or not? Some ciphers certainly are. I think there are some mostly "academic" weaknesses, but I don't think there's much outside of using problematic ciphers. The only thing I can think of off the top of my head is SHA-1 being replaced by SHA-256. I think use of GCM to replace CBC is a thing too, but I think that was done more as a performance enhancement rather than a security concern. I'll have to look it up again. That's is pretty good. Now, completely apart from this discussion, you have me curious. What are these radio modules used in? Is this something that an enduser touches, or is it to allow the engineers designing the device to configure the radio as part of the design spec? I'm wondering if any of those AT commands can be issued directly from the device using these modules or if they require a separate engineering connection.
|
|
#
?
Oct 12, 2017 08:26
|
|
|
Volguus posted:I don't agree with that. Using either SSL or TLS you get a secure socket communication. The protocols are different yes, but the outcome is the same. The underlying protocol is only relevant to those that know the differences between the two, their flaws and strengths. I agree that TLS 1.0 is rebranded SSL 3, but after that they are too different to call it the same. Just because the intent behind their design is similar doesn't make it okay to use their name interchangeably. Are we going to call IPSEC as "SSL" now? Likewise you don't say UDP when you mean TCP, yet both carry data over - outcome is the same, you transferred data. Ok it's an extreme example because UDP is stateless and TCP isn't, but you get the idea. I expect security people, or people who deal with these protocols, or any engineer really, to understand the difference but most importantly to understand there is a difference. When F5 tells you they do "SSL Inspection" they mean "TLS Inspection" (in fact, I believe they really mean HTTPS inspection). I don't know, it's just a pet peeve of mine I guess, but I believe in absolute precision. Just because people have a bad habit doesn't make it okay.
|
|
#
?
Oct 12, 2017 08:35
|
|
|
Do you get upset when people say “TLS” without a version specifier? SSL and TLS form a line of versions with a branding change for political reasons, and generalizing to “SSL” isn’t really worse than using “TLS” to mean 1.0 through 1.3. (Did you ever say that your browser was making a SPDY request, in your quest for absolute precision?)
|
|
#
?
Oct 12, 2017 11:33
|
|
|
Subjunctive posted:Do you get upset when people say “TLS” without a version specifier? SSL and TLS form a line of versions with a branding change for political reasons, and generalizing to “SSL” isn’t really worse than using “TLS” to mean 1.0 through 1.3. (Did you ever say that your browser was making a SPDY request, in your quest for absolute precision?) TLS 1.3 is vastly more different from SSL 3.0 than it is from TLS 1.1 or 1.2 (if only because of the TLS Extension support), but you point isn't half bad. There's no such thing as a "SPDY request". It's still HTTP on top of SPDY so it's perfectly fine to say HTTP request. 
|
|
#
?
Oct 12, 2017 11:42
|
|
|
behold, ladies and gentleman, the company with all your info: https://twitter.com/briankrebs/status/918466643168251904 heh, it's kind of comical in a tragic way.
|
|
#
?
Oct 12, 2017 14:49
|
|
|
orange sky posted:behold, ladies and gentleman, the company with all your info: quote:For several hours on Wednesday the site was compromised again, this time to deliver fraudulent Adobe Flash updates, which when clicked, infected visitors' computers with adware that was detected by only three of 65 antivirus providers.
|
|
#
?
Oct 12, 2017 16:10
|
|
|
orange sky posted:behold, ladies and gentleman, the company with all your info: lol flash
|
|
#
?
Oct 12, 2017 16:14
|
|
|
Proteus Jones posted:I think there are some mostly "academic" weaknesses, but I don't think there's much outside of using problematic ciphers. The only thing I can think of off the top of my head is SHA-1 being replaced by SHA-256. I think use of GCM to replace CBC is a thing too, but I think that was done more as a performance enhancement rather than a security concern. I'll have to look it up again. That type of radio is generally used by an application microcontroller over a serial connection SPI, UART, USB. By using the stack in the radio you can have even the tiniest 8bit microcontrollers communicate over a secure modern TLS socket connection. Radios like that one can be found in such diverse things as vending machines, medical equipment and remote industrial controls. Basically all sorts of things that do not need high speed connections but could use a connection for telemetry, an alarm or low speed data.
|
|
#
?
Oct 12, 2017 16:19
|
|
|
orange sky posted:behold, ladies and gentleman, the company with all your info: Screw Equifax, everyone should use TransUnion instead https://arstechnica.com/information-technology/2017/10/equifax-rival-transunion-also-sends-site-visitors-to-malicious-pages/ oops
|
|
#
?
Oct 13, 2017 07:00
|
|
|
The year that keeps on giving https://twitter.com/x0rz/status/918749189969989632
|
|
#
?
Oct 13, 2017 09:07
|
|
|
That's a joke repo. The Git equivalent of a fork bomb.
|
|
#
?
Oct 13, 2017 09:09
|
|
|
Ahah I'm on my phone, thanks,checked it out
|
|
#
?
Oct 13, 2017 09:19
|
|
|
We've still got this to look forward to, though! https://twitter.com/GossiTheDog/status/918753997502255104 We should call this "The Infosec Scare Thread"
|
|
#
?
Oct 13, 2017 09:38
|
|
|
Infosec is minimum 50% theatre.
|
|
#
?
Oct 13, 2017 12:55
|
|
|
cheese-cube posted:Infosec is minimum 50% theatre. Now that you say it, it sucks it has to be. If you give them a song and PoC they are much more likely to fix poo poo compared to just stating there is a vuln and they should upgrade.
|
|
#
?
Oct 13, 2017 13:58
|
|
|
EVIL Gibson posted:Now that you say it, it sucks it has to be. what's the ROI on a song
|
|
#
?
Oct 13, 2017 14:04
|
|
|
orange sky posted:what's the ROI on a song Less than the average cost of code name+ logo for your vulnerability
|
|
#
?
Oct 13, 2017 14:07
|
|
|
EVIL Gibson posted:Less than the average cost of code name+ logo for your vulnerability Garbage like that shits me to tears. Heartbleed is mostly to blame, albeit inadvertently, for the trend of branding and marketing vulnerability disclosure for fame and/or fortune. IMO if you consider "inventing a snappy name and registering a domain for the vulnerability" a pre-requisite for full disclosure then your vuln is probably trash. Oh and if you setup a "disclosure countdown clock" you can gently caress right the hell off.
|
|
#
?
Oct 13, 2017 15:02
|
|
|
So... Endless Septemper isn't over yet: Something "big enough that you may have to replace all your access points", which will be covered in a paper entitled "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2", and which is related to the problems with 4-way handshake that was demonstrated at DEFCON using a man-in-the-middle attack against a OpenBSD client is about to be released in less than 24 hours, so keep an eye out for CVE-2017-13077, 13078, 13079, 13080, 13081, 13082, 13084, 13086, 13087, 13088. BlankSystemDaemon fucked around with this message at 21:39 on Oct 15, 2017 |
|
#
?
Oct 15, 2017 21:34
|
|
|
I hope it needs me to ditch my APs since they are poo poo but aren't old enough to justify replacing yet
|
|
#
?
Oct 15, 2017 21:56
|
|
|
D. Ebdrup posted:So... Endless Septemper isn't over yet: lol more MORE
|
|
#
?
Oct 15, 2017 22:02
|
|
|
D. Ebdrup posted:So... Endless Septemper isn't over yet: Billie Joe Armstrong is never waking up at this point. 
|
|
#
?
Oct 15, 2017 22:06
|
|
|
I hope that is not as serious as it sounds. Still, my company's core business is network products and services so, silver lining?
|
|
#
?
Oct 15, 2017 22:11
|
|
|
orange sky posted:I hope that is not as serious as it sounds. I'm no expert, but the paper is out: https://lirias.kuleuven.be/bitstream/123456789/547640/1/usenix2016-wifi.pdf And it does look serious, very possibly "replace all your APs" serious.
|
|
#
?
Oct 15, 2017 22:13
|
|
|
mllaneza posted:I'm no expert, but the paper is out:
|
|
#
?
Oct 15, 2017 22:49
|
|
|
Wiggly Wayne DDS posted:that paper is from 2016, people have only been citing it in regards to prior known design issues. i wouldn't be shocked at places picking it up and saying it's the real thing though Yeah the new stuff is https://twitter.com/Nick_Lowe/status/919527451570638848
|
|
#
?
Oct 15, 2017 22:54
|
|
|
Absurd Alhazred posted:Billie Joe Armstrong is never waking up at this point. 
|
|
#
?
Oct 15, 2017 22:57
|
|
|
orange sky posted:I hope that is not as serious as it sounds. It's fairly serious since it appears to be related to how eapol works, so it's going to hit across the board. My company is same, I'll have to start a pool with my group on how fast a hot fix will be deployed. I imagine consumer devices are going to be hit harder in terms of getting timely fixes. Or any at all since many of them may be past end-of-life. Those are devices people tend to use until they break. I ended up buying my brother a modern wireless router when he casually mentioned he was still using some 2.4GHz only abomination.
|
|
#
?
Oct 16, 2017 00:41
|
|
|
Hopefully LEDE can patch it and it’s not baked into the SOCs.
|
|
#
?
Oct 16, 2017 00:42
|
|
|
Proteus Jones posted:I imagine consumer devices are going to be hit harder in terms of getting timely fixes. Or any at all since many of them may be past end-of-life. Those are devices people tend to use until they break. I ended up buying my brother a modern wireless router when he casually mentioned he was still using some 2.4GHz only abomination. Even if they got updates, good luck getting people to update them.
|
|
#
?
Oct 16, 2017 01:20
|
|
|
Wow, both TKIP and AES-CCMP? There is literally nothing to use unless we talk about GTK which I'm seeing has an attack against it already. Looks like people did work on hostapd to create better secure rng in response to this awhile back. So pfsense and openwrt images might be my next project (pfsense was already a project since I want to run VPN and better monitoring )
|
|
#
?
Oct 16, 2017 01:45
|
|
|
So there's been a lot of talk about the update aspect from the AP side, but since this is an issue with the handshake wouldn't it also require client updates? If that's the case I think the APs would just be the tip of the iceberg.
|
|
#
?
Oct 16, 2017 02:27
|
|
|
wolrah posted:So there's been a lot of talk about the update aspect from the AP side, but since this is an issue with the handshake wouldn't it also require client updates? The AP is the one responsible for creating the group keys which is prone to the random problems.
|
|
#
?
Oct 16, 2017 02:41
|
|
|
wolrah posted:So there's been a lot of talk about the update aspect from the AP side, but since this is an issue with the handshake wouldn't it also require client updates? I'm hoping the protocol weakness can be addressed by adding a check on the authenticator against the S-nonce.(I'm making an assumption based on the "nonce reuse" that its exploit is reuse on the supplicant side)
|
|
#
?
Oct 16, 2017 02:42
|
|
|
Double Punctuation posted:Hopefully LEDE can patch it and it’s not baked into the SOCs. No kidding. Although this finally did spur me to upgrade my OpenWRT installation to LEDE (I'd only found out about the OpenWRT->Lede thing semi-recently, my fault)... you can make fun of me now.
|
|
#
?
Oct 16, 2017 07:00
|
|
|
|
| # ? May 12, 2024 20:46 |
|
|
EVIL Gibson posted:The AP is the one responsible for creating the group keys which is prone to the random problems.
|
|
#
?
Oct 16, 2017 08:00
|
|