Live data from Hacker News

Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

bleepingcomputer.com

81–90 of 123 posts

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#81
post #72

Earlier quoted context omitted.

iTunes for Windows is hot garbage

They want you to buy a Mac. It's likely somewhat intentional.

iTunes for Mac is slightly less-hot garbage.

They need to refactor the monolithic app that does everything into smaller, more focused apps. My media player shouldn't also do document management for my phone.

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#82

Hmm, I recently picked up a pair of pxc 550s (crazy good black Friday deal), and I saw the thing about installing their android/iphone app to do NFC pairing, but I frankly have no idea why you would want that, or really much of anything else in the app. The reviews even mention that the eq controls don't even work for DRM'ed content. OTOH, it seems if you pair the headphones with normal bluetooth its just using A2DP/…

RMA for miserable sound ?

Bluetooth is absolute garbage for serious audio. Wired will always sound better, and a DAC + Amp driving the cans will always sound the best.

Sennheiser does make BT headphones with a dedicated tower that helps a bit, but nothing can replace a hard line.

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#83
post #32

Earlier quoted context omitted.

Yeah, because on Linux the community has to support the hardware because the manufacturer doesn't even bother. Sounds way better...

I would like to inform you that it does in fact work really rather well. I write this on a laptop running Debian Linux which I use for work. It's great. I also use a machine running Debian Linux for my personal computing needs, but prefer to separate those concerns a bit. I can confirm the community's support is excellent though.

It doesn't work at all, for the thousands of pieces of hardware that simply don't work on Linux, or work poorly.

Further, it doesn't work at all from an economics standpoint. There is zero incentive driving the community to support every iteration of every type of hardware other than personal need, and if you're suggesting that anyone who needs something has to go out and build a driver themselves, please let me know who your dealer is because I want to be as high as you.

As for, "the community is better than the manufacturer" try having an outage over the holidays, and see how your community reacts to, "help me or my business fails".

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#84

Lots of security flaws in code recently. FB and Google+ both leaked, Instagram had a minor leak a week or so ago. It's hard to put blame, I've coded just a bit in my life but I get it how hard it is to write a truly secure and efficient code. Well, on the bright side users can protect themselves against MITM attacks by using a VPN. I'm using Surfshark right now, have tried Zenmate, PIA before, but had some minor issu…

If this isn't an ad for Surfshark, you need to work on your delivery. If it is, shame.

Sorry if that sounded promotional, but VPNs do in fact protect against MITM attacks. And the service I mentioned I found reliable so I felt like the information was relevant, but point taken for future notice :)

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#85
post #72

Earlier quoted context omitted.

They want you to buy a Mac. It's likely somewhat intentional.

iTunes for Mac is slightly less-hot garbage. They need to refactor the monolithic app that does everything into smaller, more focused apps. My media player shouldn't also do document management for my phone.

[deleted]

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#86
post #32

Earlier quoted context omitted.

I would like to inform you that it does in fact work really rather well. I write this on a laptop running Debian Linux which I use for work. It's great. I also use a machine running Debian Linux for my personal computing needs, but prefer to separate those concerns a bit. I can confirm the community's support is excellent though.

It doesn't work at all, for the thousands of pieces of hardware that simply don't work on Linux, or work poorly. Further, it doesn't work at all from an economics standpoint. There is zero incentive driving the community to support every iteration of every type of hardware other than personal need, and if you're suggesting that anyone who needs something has to go out and build a driver themselves, please let me know…

I see your _thousands_ of pieces of hardware that don't work and raise you all the hardware written for old versions of Windows whose drivers no longer work on new versions yet still work _perfectly_ on Linux.

See: professional audio and video gear, perfectly good network cards.

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#87

Earlier quoted context omitted.

OpenBSD's official FAQ has this to say about Flash: Adobe's Flash plugin is distributed in binary form only, and they do not provide a native OpenBSD version. Considering their security record, we thank them for this neglect. The situation is equivalent here; given the kind of software that hardware manufacturers tend to write, I'm quite happy to take volunteer efforts over what they produce.

Every BSD system I’ve used never had X installed, let alone a web-browser - but now I’m curious what a text-mode Flash player would be like.

Maybe your use case didn't involve X, but BSDs do make a decent (graphical) desktop.

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#88

Earlier quoted context omitted.

It doesn't work at all, for the thousands of pieces of hardware that simply don't work on Linux, or work poorly. Further, it doesn't work at all from an economics standpoint. There is zero incentive driving the community to support every iteration of every type of hardware other than personal need, and if you're suggesting that anyone who needs something has to go out and build a driver themselves, please let me know…

I see your _thousands_ of pieces of hardware that don't work and raise you all the hardware written for old versions of Windows whose drivers no longer work on new versions yet still work _perfectly_ on Linux. See: professional audio and video gear, perfectly good network cards.

You need to match my bet in order to raise it, and you didn't even come remotely close.

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#89
post #71
post #69

I'm a little lost on why the need a new root CA cert on a computer that already has a cert store. Can't they safely communicate with whatever.sennheiser.com using the existing certs? Afaict, this isn't a stand-alone device trying to communicate, but your computer, running some app. What am I missing? Edit: okay, I see below that they are using a local web server, and (thanks to browser decisions about localhost) it r…

The really silly thing is that it's 2018 and the browser vendors still refuse to implement name based constraints on certificate authorities. It should be perfectly reasonable for a local, single domain CA to be generated and installed with the application. Instead we treat every CA as worthy to handle every domain always.

I'm not sure that's a browser thing.

The X.509 spec specifies a field for that, which in OpenSSL would be called "subjectNameConstraints". The rules for the constraint can be found in RFC5280.[0] Mozilla have had an open development track for CA name constraints for quite some time, but the last edit to the page is from 2015.[1]

I tried to actually use this field couple of years ago, and none of the existing tools I tried had any support for it. OpenSSL would fail to parse a CSR config with this key. Same for Go's TLS library.

So of course I did what any enterprising hacker would do: I created a CSR manually with the correct OID in place. Trying to sign that was nothing short of hilarious. Loading up the CSR into OpenSSL would trigger a BIO_read_* error. Trying the same with Go's TLS library triggered a panic!

I then realised that if you could somehow supply a certificate chain with a name-constrained CA in it, it would act as a highly reliable DoS against virtually all clients. (Probably against servers too, if you supplied a client-cert chain.)

Based on discussions since, I have been informed that Microsoft's TLS stack supports this - or at least should be technically capable of issuing CAs with the field in place. But because practically nothing else in the world has the support, and is in fact likely to crash when presented with one, even a gradual rollout is simply not possible.

Hence every single CA you see will be valid for *.

0: https://tools.ietf.org/html/rfc5280

1: https://wiki.mozilla.org/CA:NameConstraints

Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks

#90
post #7

Earlier quoted context omitted.

I run some services for my private use. It's crazy that I need to have them certified by some third-party over-seas CA since I can't get my own devices to trust my own certificates. We're not at that point yet, but running your own trust root is getting quite annoying. For example, Android constantly nags about "network might be monitored" when custom certificates are installed.

Android constantly nags about "network might be monitored" when custom certificates are installed. It won't if you add name constraints to your root certificate (because then it can't be used for blanket monitoring).

Does this actually work now? A name-constrained CA (or even its CSR) used to break things in absolutely hilarious ways.
Post reply on HN