From smart TVs to this. How awful.
Software is eating perfectly good peripherals and _totally_ ruining them.
Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
31–40 of 123 posts
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#32Have any hardware companies ever written good accompanying software? From all the custom-ui graphics card config nonsense to utilities that phone home of their own accord, to things like this which are laughably awful. I feel glad I left for the mild shores of Linux in the early 00s.
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.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#33The comfort in this article is knowing for every boutique german headphone company that insists on becoming a CA, there are thousands of nameless chinese companies producing superior products at lower prices that do to some measure respect the users privacy in that they arent more than just a USB peripheral.
Sades and Xiberia for example make perfectly useful (if not a little bit cyberpunk) headsets that just operate as USB soundcards with no special CA requirement.
And if you're just in the mood to listen to some music without special software in this foul year of our lord 2018, Might i suggest a pair of Superlux 668B's? for ~$40 theyre easily better than anything Sennheiser produces that requires its own PKI.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#34Earlier quoted context omitted.
I have to STRONGLY disagree. It's a slippery slope towards a world in which the computers we use are completely locked down and we have no control over what they trust, being dictated by the corporations and their interests. The freedom to modify your roots of trust is extremely important and situations like this should not scare us into depriving ourselves out of that. I say this as someone who runs an adblocking/fi…
In practice the corporation "dictating" the set of publicly trusted CA roots is the Mozilla Foundation, a 501(c)(3) non-profit with a large volunteer effort. On paper all the major browser vendors / operating system vendors (Microsoft, Apple, Google, Mozilla) have independent root trust programmes. But after several years working on this stuff I would say that all real public oversight is done by Mozilla, which AFAIC…
> In practice the "corporation" "dictating" the set of publicly trusted CA roots is the Mozilla Foundation, a 501(c)(3) non-profit with a large volunteer effort.
Why the scare quotes on “corporation”? Mozilla Foundation is a corporation. Here are he articles of incorporation: https://www-archive.mozilla.org/foundation/documents/mf-arti...
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#35This seems like pure laziness. Did the developers really not have an understanding of basic PKI? Or did they realize late in the game that their local web socket was gonna require HTTPS and slap this on at the last minute?
Why should developers care if customers don't?
Do we know about a one B2C company who lost the business due the security breaches in their products?
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#36Earlier 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.
Nobody will issue Sennheiser a certificate for this purpose. Every so often a company abuses a cert they were issued to do what Sennheiser wanted to achieve here (local loopback HTTPS) and when they're caught the cert is revoked and they get a slap on the wrist. Blizzard is a recent example. The Right Thing (TM) is to not do HTTPS, a modern web browser is supposed to conclude that ::1 and 127.0.0.1 are secure without…
Blizzard ended up doing it the right way.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#37Earlier quoted context omitted.
It's perfectly normal to install new root certificates - for example, so that a company can sign internal websites (or for MITM proxies). It's incredibly shady to have random software install into your trust store.
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.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#38Earlier 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.
burned how exactly?
It can be a real pain in the butt to go up and down the whole stack and reconfigure every library and application that might detect a insecure connection and bail. Need several independent webapps to communicate? Hoo boy.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#39Earlier 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.
Actually the support from community is often much better than from the vendor. Especially for the older hardware, which works perfectly fine, but just have no drivers for modern Windows.
The main problem with hardware support in Linux is there is no up-to-date source of information about what works and what doesn't (and everything in between). You can usually find info about particular piece of hardware, but it lacks the main purpose of such a database - to make more people to buy more open hardware.
Re: Sennheiser Headset Software Could Allow Man-In-the-Middle SSL Attacks
#40Earlier 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.
Nobody will issue Sennheiser a certificate for this purpose. Every so often a company abuses a cert they were issued to do what Sennheiser wanted to achieve here (local loopback HTTPS) and when they're caught the cert is revoked and they get a slap on the wrist. Blizzard is a recent example. The Right Thing (TM) is to not do HTTPS, a modern web browser is supposed to conclude that ::1 and 127.0.0.1 are secure without…
If you want an arbitrary (thus https based) website to be able to communicate with a localhost server using websockets you are forced to use https on the localhost server. This is because the browser won't connect to non-secure websockets from an https website, even if the websocket is to localhost.
The actual right thing to do is to generate a private key and certificate (for a specific, public name you point to 127.0.0.1) during the software installation and add the latter to the trusted store. Now you don't have this vulnerability because each computer has a different trusted certificate with a different key, so a random attacker cannot just use the key they got to spy on other users.