Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

71–80 of 89 posts

Re: OpenSSL Security Advisory

#71

Post by gonzo »

tedunangst wrote: post #58
jacquesm wrote: post #46

Earlier quoted context omitted.

Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?

Common request, but no. First and foremost, the accounting overhead is annoying. If I spend two days at a hackathon working on smp, do I have to charge the hotel to a different account? Can I pretend the libressl work I did for free this week is exchangeable for paid work during a hackathon? It very quickly becomes a mess. I think you get a pretty decent return on investment even if your dollars support openbsd featu…

> Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl.

even though the "exploit mitigation" didn't work with Heartbleed, which was the reason libressl started.

Re: OpenSSL Security Advisory

#72

Post by tedunangst »

gonzo wrote: post #71
tedunangst wrote: post #58

Earlier quoted context omitted.

Common request, but no. First and foremost, the accounting overhead is annoying. If I spend two days at a hackathon working on smp, do I have to charge the hotel to a different account? Can I pretend the libressl work I did for free this week is exchangeable for paid work during a hackathon? It very quickly becomes a mess. I think you get a pretty decent return on investment even if your dollars support openbsd featu…

> Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl. even though the "exploit mitigation" didn't work with Heartbleed, which was the reason libressl started.

Yes, that's what I just said. If OpenBSD hadn't included exploit mitigation, it wouldn't have not worked, and we wouldn't be here today.

Re: OpenSSL Security Advisory

#73

Post by e12e »

apendleton wrote: post #64
e12e wrote: post #63

Earlier quoted context omitted.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)? And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot.…

To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP pa…

> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.

I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway?

None of this helps with a rouge AP, of course -- so it might be a bit academic.

Re: OpenSSL Security Advisory

#74

Post by Sammi »

tedunangst wrote: post #72
gonzo wrote: post #71

Earlier quoted context omitted.

> Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl. even though the "exploit mitigation" didn't work with Heartbleed, which was the reason libressl started.

Yes, that's what I just said. If OpenBSD hadn't included exploit mitigation, it wouldn't have not worked, and we wouldn't be here today.

I had to read that about five times to understand it :) Reading "had not" and "would not" on the fifth attempt did the trick.

Re: OpenSSL Security Advisory

#75

Post by apendleton »

e12e wrote: post #73
apendleton wrote: post #64

Earlier quoted context omitted.

To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP pa…

> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway. I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway? None of this helps with a…

In infrastructure mode, all WiFi traffic goes through the access point. Whether or not, from a configuration perspective, the access point lets you meddle with traffic that passes through it is a separate question, but I don't think there's anything wireless-protocol-wise that precludes it.

Re: OpenSSL Security Advisory

#76

Post by e12e »

e12e wrote: post #73
apendleton wrote: post #64

Earlier quoted context omitted.

To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP pa…

> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway. I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway? None of this helps with a…

(side-reply as direct reply is either in cool-down or limited due to depth)

Interesting, I hadn't really looked into 802.11alphabetsoup in terms of ad-hoc vs infrastructure -- wasn't aware the ap was a bottleneck. The natural next question is if there are any standard secure forms for ad-hoc networking?

It would seem that shared-secret should be easy enough (but probably with the same/similar security issues as other shared-media networks in addition to the possibility of guessing the key). Some form of certificate authentication, or kerberos like shared-secret-trusted-mediator should be possible? But having a look around, I can't seem to find any - certainly not any that could be expected to work with standard OSs and devices...?

I suppose one could simply use an unsecured ad-hoc network + vpn for routing? Still I don't know of any VPN-styles that would allow broadcast traffic over such a mesh network?

[edit: It would appear the olpc projects has done some work in this area: http://wiki.laptop.org/go/Mesh_Security

ed2, also: http://wiki.laptop.org/go/Mesh_Network_Details

And: https://github.com/cozybit/open80211s/wiki/HOWTO ]

Re: OpenSSL Security Advisory

#77

Post by vacri »

clarry wrote: post #49
jacquesm wrote: post #46

Earlier quoted context omitted.

Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?

That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding en…

Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"?

Yes. One the one side you have a group called 'employers'. On the other side you have a group called 'contractors'. Contractors are free to work on whatever they feel like, but if they also want money, they should probably do some work for employers from time to time.

It's hardly rude to say "I value this, here is some money to help this along". If the devs see that plenty of people are giving money to 'this', then if they don't work on it, that channel will dry up. Donations aren't a gift like a christmas present, which you get to use on whatever you want. Donations are an enabling device usually intended for a particular cause. They don't mean you get to dictate the actions of the staff, but at the same time, the staff shouldn't be taking donations for work they don't care to do.

Re: OpenSSL Security Advisory

#78

Post by Florin_Andrei »

TillE wrote: post #67
Florin_Andrei wrote: post #59

Earlier quoted context omitted.

> Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'. Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.

I think some people have also forgotten what a complete disaster Microsoft was right up until the mid 2000s. IE exploits, Windows exploits, IIS exploits (remember Code Red?). They well and truly earned their reputation.

Teardrop was fantastic.

Re: OpenSSL Security Advisory

#79

Post by thegeomaster »

apendleton wrote: post #75
e12e wrote: post #73

Earlier quoted context omitted.

> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway. I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway? None of this helps with a…

In infrastructure mode, all WiFi traffic goes through the access point. Whether or not, from a configuration perspective, the access point lets you meddle with traffic that passes through it is a separate question, but I don't think there's anything wireless-protocol-wise that precludes it.

Just to add—in open networks masquerading as the AP is possible so long as you can reach the hosts with your Tx. This is mitigated with encryption, however, as I understand the WPA2 standard, I suppose you could send out a broadcast ARP response packet encrypted using the Group Transient Key pretending to be the AP. However, probably all sane clients would discard ARP responses that were broadcast, as normally, ARP responses should always be unicast to the requesting client.

Edit: Looks like I was spot-on! This is a real vulnerability, and is called Hole 196: http://www.airtightnetworks.com/wpa2-hole196.

Re: OpenSSL Security Advisory

#80

Post by PhantomGremlin »

ZoFreX wrote: post #30
mnw21cam wrote: post #18

Earlier quoted context omitted.

It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.

Completely unscientific observation: More people in my local coffee shop are using phones than laptops, and more of those phones are Androids than iOS. I know anecdotally that the Chrome browser is very popular on Android. I would give even odds on there being more people to exploit with this than there were with goto fail.

I use coffee shop WiFi when I access useless sites such as Drudge Report. However, it's not hard to either

a) switch to cellular on a phone before accessing something important like a banking site

or b) use something like Personal Hotspot together with a phone switched to cellular to allow a laptop to access something important like a banking site

That's what I do. I certainly don't trust random WiFi for sensitive communications.

IMO you're much safer relying on AT&T or Verizon to connect you to key sites via cellular service rather than thru WiFi. OTOH I know that in the past AT&T has automatically switched my iPad from cellular to WiFi when I was at a coffee shop that had service from them. So this may be a little tricky in practice.

Post reply on HN