Hacker News Reader

Comment by StudentStuff | Hacker News Reader

If only we had these kinds of strong warnings in the VOIP industry. Nearly every provider barebacks the internet, throwing unencrypted signaling data (phone number dialed, keys pressed during the call, codec to use) and call media over the internet raw, just hoping that no one eavesdrops or alters their data.

HIPPA compliance? Nah bruh, unencrypted UDP is just fine! PCI-DSS says we can't take credit cards over this wholly insecure connection? Who cares! Just don't let the auditor near our PBX.

Sadly, the HTTPS and IPv6 anti-vaxxer crowd is strong in the VOIP community, if it isn't severely painful to the VOIP company themselves, they aren't going to secure it. Not that they'd secure it properly anyway, even if their livelihoods depended on it...

View on HN

I've seen PBX people find religion once they wake up Monday morning to a weekend of hacked calls to Africa. Though sometimes that religion is in the form of yelling at upstream providers to please give them refunds.

And because of these insecure systems, the more serious issues (all this SIP software is tons of C, and I've found exploits in just 1000 line utilities, let alone protocol level hackery and other fun) get ignored. I found a simple redirect bug in a VoIP platform. Ignored. Later some guy used it to the tune of $90K.

I don't want to become a criminal outright but I've gone from a "friendly disclosure offline and let you lie about fixing issues" to "Sit on 'em and sell 'em one day" model because everyone's so obtuse.

SIP... doesn't seem like the greatest protocol. Maybe I'm tainted because I've only really dealt with it in the context of the Microsoft IM/telephony platforms (renamed constantly, but always essentially the same), but it appears to be incredibly brittle complicated. On anything less than a local LAN, messages get dropped or mangled or timed out all the time, and that trashes connections, or puts sessions into unrecoverable states.

I guess you can argue about whether it's the greatest protocol, but the problems you describe most certainly are not procotol problems, but rather broken implementations.

The protocol problems are due to the text-based format and a bizarre desire to make said text format "human friendly". It inherits the stupidity from HTTP (line folding, comments in headers) and adds its own fun. The authors actually suggest that the "intent" of the message be followed in case of errors. It's terrible. The packet issues are due to the strange use of UDP with mandatory TCP switching. Needless complexity.

Oh and these aren't theoretical. Two big, widely deployed implementations cannot even agree on how headers end, and will read the same message differently. This can be exploited when a network does header processing. Imagine adding a "x-accountid" header, and removing any existing ones - if interpretation differ on what constitutes a header, an attacker can slip fake headers in. Not entirely dissimilar to browser exploits that let script include a header with a newline in the value, letting scripts maliciously set headers they shouldn't be allowed to.

Well, yeah, I certainly didn't mean to say that SIP is a great protocol, it is indeed quite terrible--but still in practice if things don't work, that's usually a result of at least one party not following the spec (which is not really surprising , given all the pointless complexity ... but then that's still not really an excuse to not implement SIP when you are claiming that you do).

Practically, it is not possible to implement the spec in an interoperable way. Existing implementations are mutually incompatible. Hence the need for config flags per "trunk". What one system requires, another will reject. Sad but true.

Well, yes. But still, more often than not, when I encounter interoperability problems, if both sides actually did what the spec says, there wouldn't be a problem. SIP itself is quite sad, but in my experience many implementations are even worse than the spec.

NAT punching with SIP has gotten worlds better in the past few years. The protocol itself is sufficient, its just actual implementations that are piss poor at this point, missing even basic stuff like IPv6.

Yeah, "security" people in the VOIP industry can't get their head out of their own ass. Seen it too many times myself!

In my experience, the entire world runs on insecure systems (and will continue to do so until companies start getting sued into oblivion for leaking data). Secure systems are the exception--not the norm. It's just not a priority because companies only prioritize things that "add value". So until we attach a real cost to lack-of-security, it won't be valued.

I've literally seen a college have admin credentials hosted on a publicly addressable plaintext document just so that their new machines can netboot. And that's just one, quick, story out of dozens upon dozens I have.

Admins are lazy and busy, hence why UW for example runs a totally insecure PBX, which is surprising considering Avaya is usually one of the better vendors.

Admins lack management support for security issues.

What are VOIP systems used for these days? Private enthusiasts or some company call centers? I've no idea, as I haven't seen one for at least half a decade now -- even all conference calls are always over Skype or Hangouts.

The largest VOIP companies in America today are the cable companies, ACN (pyramid scheme with a few million VOIP customers), Vonage (a first mover) then a few dozen minor players that are near the half million customer mark. IMO its a big (but unsurprising) marketing failure.

VOIP as a product never really made it into the home, despite all its features and enhancements. Instead, it is limited to the realm of businesses, where it is in most hospitals, medical facilities, chain stores, call centers, and so on.

All landline phone connections sold by Telekom in germany are VOIP, it's just mostly hidden from the subscriber. The technology is doing perfectly fine.

VOIP and specifically SIP in its least secure form became the replacement for old tandem circuits. Sadly, rather than pushing SIP hardware out to the endpoints, most lamdline carriers chose to just provide twisted pair service.

VoLTE is as close as most consumers will get to proper VOIP service.

Giving everyone SIP phones is expensive, and forcing your subscribers to purchase SIP phones will ensure a number of them flee to the competition. Putting the VOIP hardware in the modem makes much more sense, because you have to provide that to your subscribers anyway.

I actually have my own Cisco Phone adapter to connect my old analog phone/answering machine. I'd assume that a true SIP phone would work as well. What's questionable is whether I could authenticate from a different network than my home network.

I know, however, that both Vodafone and Telekom in Germany offer products that allow connecting VOIP phones from anywhere to a virtual phone appliance.

That's interesting. In the Netherlands, all the telcos (with the notable exception of XS4ALL) lock down the modems and don't give you the settings and logins to use your own equipment (although the Consumer and Market Authority is still researching whether this is actually legal).

Locking the connection to a provided modem is not legal in Germany since 2016-08-01 by law (FTEG, replaced by FuAG in 2017) The provider is obliged to hand you the required credentials to connect your own hardware, though getting the actual required configuration may require some puzzle work, but most providers give config examples for at least the most common hardware. My setup for example consists of a draytek modem with unifi network hardware and above mentioned Cisco phone adapter. I don’t even have a piece of Telekom-provided hardware here. Took a bit of googling to get IPTv working, but other than that it’s a perfectly stable and capable setup. Many people use Fritz boxes which are a bit less capable but easier to set up.

I'm assuming you're talking about consumer VoIP; in the corporate world, Cisco (and presumably others) do a crapload of VoIP office phones.

I also haven't seen an office phone in ages, it's just all mobiles around here.

It's because you don't do bulk calls. Sells, support, orders, etc. They all need office phones at a certain scale. Not that they couldn't do it with mobiles. But infrastructures for those kind of systems all assume a land line.

Decent deskphones are significantly more comfortable than cellphones, nevermind the better audio hardware.

You could make special apps with a UI made to help with the specific tasks, and with a good bluetooth headset make a nice mobile experience IMO. But yeah currently solid IRL keypads + phone handles are better than mobiles'.

I've worked for pretty much every type of company except VC-funded Silicon Valley style start-ups since about 2008. Every desk I've ever sat at, including the one I'm at now, has had a VoIP phone sitting on it.

In the early days at Nest, one of my co-workers had trouble with his loan application because Nest, his employer, didn’t have a phone number. He showed the bank the company’s web site, and they were satisfied. Only a real company would have an actual web site.

For added fun, the site looked like this at the time https://web.archive.org/web/20110207225932/http://nestlabs.c...

Is your entire daily experience only between your home and office and car? You don't even have to go to an office to see non-mobile phones.

You've never noticed the phones at every checkout stand in the grocery store? Or at every customer service desk in every retail store in the nation? Or hotel front desks?

When that new coffee shop opens down the street and isn't on Yelp yet (or is, but the hours are wrong anyway), how do you find out its hours? Do you ask the barista for his Facebook ID? How do you find out information about a place that doesn't have a web site, or that has an obviously outdated web site? Have you never worked in a place with a receptionist?

The only place I've ever worked that didn't have telephones turned out to be a scam operation. I don't think I would trust a company that didn't have phones.

You are almost certainly an exception. The next time you are out in public, just look around. VoIP phones are everywhere.

Hell, I have a Cisco VoIP phone on my desk in my home office, tied into $work's phone system.

(I actually have three VoIP phones here at home, but I'm a network engineer for an ISP/CLEC.)

I've seen a lot of tech companies use appear.in or talky.io for their VoIP conferencing as well

"the HTTPS and IPv6 anti-vaxxer crowd "

What does this mean?

Pretty sure that means people who refuse to deploy TLS & IPv6, even when their hardware & software stack fully supports it.

That makes more sense than trying to force a completely unrelated opinion into a conversation.

Also, the notion that broad use of IPv6 = security in VOIP, IoT or any area is a postulation at best.

I've personally always found this to be a good overview of security issues involved in both protocols in VOIP:

http://ieeexplore.ieee.org/abstract/document/6714161/

(Sci-Hub approved)

There are certain parts of the industry hesitant to transition for the possibility of security mis-configurations and human errors, the picture that the VOIP industry as a whole holds no interest in security is false. It could definitely improve, but that doesn't just apply to VOIP.

It's not an opinion or unrelated but an analogy to another case where there's very strong evidence of a massive benefit with very little downside which is being objected to based on conspiracy theories and lack of concern for the damage to anyone foolish enough to believe them.

As a side note, the debate is not that simple. Vaccines work, but many vaccines are manufactured without what many would consider proper testing, and using toxic substances banned in different countries.

The debate is more about sloppy implementations than about the idea of vaccines as a whole. It's like someone is forcing the issue down to choosing poorly-regulated vaccines - or no vaccines at all. A false dichotomy.

> As a side note, the debate is not that simple. Vaccines work, but many vaccines are manufactured without what many would consider proper testing, and using toxic substances banned in different countries.

Those are big claims without any supporting evidence. From the sounds of it, you're repeating the anti-vax claims about mercury.

Ethyl vs Methyl mercury is one of the most popular debates (because mercury is scary!). Most vaccines switched to Thiomersal which has ethylmercury in it. However, even ethylmercury crosses the blood-brain barrier. Other 2 big ingredients are formaldehyde and aluminum. From there you have to get more specific about which vaccine you are talking about.

You still haven’t specified your claims. Which vaccines aren’t well tested? Which substances are included at levels known or suspected to be toxic, and by whom?

My claim is about the debate itself, not about any certain vaccine or danger.

So far you're following the anti-vax script perfectly: lots of FUD, no claims specified in enough detail to even evaluate them much less counteract the overwhelming evidence that vaccines are a public good with no reputable downside.

I've been supplying information and you've been complaining. I fail to see how I'm at fault for trying to answer questions.

You didn't just talk about the debate. You stated as a fact that many vaccines have improper testing or substances. If you state something as a fact, you should be prepared to back it up.

> You stated as a fact

You're putting words in my mouth. What I said was "...without what many would consider..."

I'm still taking about the debate itself and you're trying to make this a binary debate about vaccination.

You're still not supporting your claims. If, as you said, the debate is not that simple the onus is on you to justify the claim that there is in fact any significant debate over vaccination in the scientific community.

You stated toxicity as completely objective. (And you had better mean "toxic at the doses given", because anything is toxic in large-enough quantity.)

> What I said was "...without what many would consider..."

That's still calling them correct about the vaccines not meeting those standards. There are a lot of claims about vaccine testing that are objectively false. It's not that their standards are higher, it's that they falsely believe vaccines undergo less testing than they actually do.

I don't want this to be a binary debate. I want you to quantify 'many' and provide actual evidence of anything.

There's more mecury in the fish you eat and it's the methyl kind which sticks around for weeks. If you eat fruit, there's methanol naturally present which the body metabolizes into formaldehyde. I am willing to bet your kid gets a higher dosage of formaldehyde from the juices they drink then a vaccine.

> The debate is more about sloppy implementations than about the idea of vaccines as a whole. It's like someone is forcing the issue down to choosing poorly-regulated vaccines - or no vaccines at all. A false dichotomy

This actually goes quite strongly against what I've observed though. Literally all of the anti-vaxxers I've met are 100% against vaccines. They are not vaccinated, nor are their children.

They're not doing research and choosing to use some vaccines but not others. They're completely ignoring all vaccines.

The guidelines ask us to eschew flamebait, which means to avoid it altogether—both making it and taking it. This is what happens.

https://news.ycombinator.com/newsguidelines.html

> That makes more sense than trying to force a completely unrelated opinion into a conversation.

I'm curious, at what point does that opinion become fact? Isn't the evidence overwhelming?

I mainly ask because it feels like if the evidence for vaccination were not sufficient to warrant it as more than simply an opinion, wouldn't many other things become merely opinion too?

There are situations where you need IPv4 due to rate-limiting. So while my stack technically supports IPv6 I have no reason to migrate to it.

You've been downvoted because this shouldn't be true, but since no-one else has stepped up, I'll bite :).

It's perfectly possible to do IP-based rate-limiting in the IPv6 world, you just need to do it based on different prefixes, rather than full IPs.

As a specific example, my ISP -- as is quite usual -- hands out /48s. So in the same way that you can rate limit my entire NAT'd IPv4 connection with a single entry, you can rate limit my entire IPv6 connection with a single entry, by storing the prefix.

^^ Keys pressed... Jesus Christ, that alone has fueled entire generations of criminals. :))

Could we ask you to please comment more substantively, like the guidelines ask?

https://news.ycombinator.com/newsguidelines.html

Reply on news.ycombinator.com