[deleted]
Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
101–110 of 123 posts
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#102Earlier quoted context omitted.
> the problem is not that they add a root ca to the store. Yes there is. There is no valid reason for a glorified headphone driver to mess with what website your browser trusts.
There is a valid reason: to enable website-to-hardware communication (i.e, to provide a javascript-based api for websites to interface with that hardware). Ideally browsers should implement well standardized, secure APIs for all devices in the world, but we are far from there. Until browser vendors implement the API you need, the only option is to employ this trick. Of course, companies should NOT reuse the same cert…
[deleted]
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#103Earlier quoted context omitted.
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.
[deleted]
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#104I'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…
I work on a product that is in a similar boat. We have LAN based remote control using HTTP connections, but have no practical way of TLS enabling it. Stunts like this would work, but are a really bad idea. The other alternative is to have the devices and remote control connect to a central server over TLS and Internet and then have that server relay traffic. But that is not nice either. However we may be forced into…
[deleted]
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#105Earlier quoted context omitted.
As someone that has been burned by self signed internal only sites. Take the extra 15 minutes and get a proper cert, and domain name for your internal sites. It can save a massive amount of pain later.
Why? It you are testing applications in a dev/test system that is only a available on the company VPN then how can you get burned? Sure it’s annoying clicking through browser warnings but if it’s not public facing I don’t see the danger.
Just hope you never need an external system, or a cloud hosted service to talk to your dev/test environments. It’s so cheap and easy to do it right that it just doesn’t make sense to do it the other way.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#106Earlier quoted context omitted.
> It's also extremely common for companies to install root certificates on work computers that employees use to check their personal email. Why is nobody objecting to this? A question: if I'm on a work PC that has a root certificate installed, can you tell if they're using it to MITM? When I go to a site on my work PC with the padlock (eg my bank) and click to get more info, it does show the bank's certificate. Can t…
Of course it will show the cert with the matching name, practically all MITMs will generate the correct certificates so that browsers don't complain. You need to look at the CA it's signed with, and compare to the one you get when you access the site from somewhere else. Also, It's also extremely common for companies to install root certificates on work computers that employees use to check their personal email. Why…
>Because you do not own those computers, and they should not be used for non-work-related activity. The company policy will explicitly mention this, something like "all communications on company property are subjected to monitoring at all times."
Just as a thought experiment, lets say I set up a "free computer booth" on a street, but made people tick a box when they started that expressed the same conditions.
Would I then be entitled to MITM and read all communications that passed through that machine?
Why or why not?
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#107Earlier quoted context omitted.
burned how exactly?
In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to cle…
Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there.
And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good idea as well. Relying on an external CA for internal services just creates risks of both availability and security. If you need an external CA to set up or continue operating internal services, that is an availability risk, and if you trust the whole standard set of root CAs for all of your internal services, that's a massive security risk.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#108Earlier quoted context omitted.
It's not, not even remotely. You clearly haven't actually lived day-to-day with Linux or you'd know how buggy and unreliable the random drivers for less-than-popular hardware actually is. Further, you've clearly never had a critical outage happen during off hours. Try running to the community when your job is on the line at 3AM Christmas Day, let me know how responsive they are to you then. You get the quality you pa…
"Try running to the community when your job is on the line at 3AM Christmas Day" That's a bit extreme. Of course throwing a shitload of money at support contracts will give you helpdesks answering during holidays and drones flocking into the data center, but that applies only to a very small subset of hw/sw products where any outage can be fatal. The consumer market is just a bit different though.
It's the opposite of extreme, it's reality for every company out there, and it's not a "very small subset" it's the majority of money.
Besides, if your shit can't work when it counts, what good is it?
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#109Earlier quoted context omitted.
Apple?
iTunes for Windows is hot garbage
I didn't use iTunes for Windows, but I did use one for Mac a couple of times. I can imagine how terrible the Windows one must be if it's worse than the garbage they ship for Mac. No use case I needed from it was ever easy or worked as I wanted...
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#110Earlier quoted context omitted.
As a bit of a layman, is there even any legitimate reason at all (other than a user installing it in their own machine for reverse engineering purposes) for anyone to install a root certificate anymore? I could understand it if it was a small company doing so at the time when certificates were expensive, but Sennheiser has plenty of money and certificates can be obtained for free nowadays.
There was never a good reason to install a root certificate for the purpose of speaking securely to your own gear or web services. In that case, you don't need to add them to the root trust store, you just need to create an SSL context that has those certificates set as trusted. However, the problem is, nobody understands SSL properly. Among the people who don't understand SSL properly is, alas, a number of people wr…
what you need to do in this case is create your own root store of trust, and then stick your own certs in there from some .pems or something, and then use that to initialize SSL on your connection
Their goal was to allow the browser to connect to the local daemon, for web-based softphones, so this wouldn't work.