The government chose to stop publishing HCSEC reports after 2021. I'm unable to work out whether HCSEC itself is still operating or not.
[1] https://assets.publishing.service.gov.uk/media/60f6b6be8fa8f...
By the time any highly-technical topic makes it to the mainstream discourse, the details tend to get stripped out simply because none of the 70 year olds watching CNN or Fox appreciate the difference and none of the anchors or panelists know what they're talking about either.
We built this city
We built this city
We built this city on broken code
The US bans the sale and install of Cisco hardware? (of course not but from the context not clear)
You trust China over your own government? Move then.
I am old enough to have seen several instances where organizations had internal reasons for their decisions and chose to argue something completely different in their outward communication. Given that an exclusion of Huawei had the obvious side effect of protecting domestic markets, this leaves quite some room for doubt around this specific instance. You say it yourself that governments have mandates.
From that perspective it makes a big difference whether the Chinese have mostly secure back-doors or their software is just generally insecure.
https://www.cbc.ca/news/canada/ottawa/rcmp-chinese-police-st...
A quick search found: https://www.euractiv.com/section/politics/short_news/uk-bann...
I live in the UK. This may have been part of it, but to think that a communist dictatorship that (to pick a random example) harvests organs from political opponents is above backdooring their own kit is beyond naïve.
But I guess it’s like you said: a political experiment.
Now personally I would say that this is a crazy idea from the jump, given the usual asymmetry between attackers and defenders. But even if you grant that it's possible, it requires that you begin with extremely high standards of code quality and verifiability. Those were apparently not present.
So yeah, even if they are equal, there are A LOT of reasons to spend the extra money.
Also, even if all providers provide equally crappy versions, it's still slightly more secure to prefer a vendor in your own or an allied nation. At least your interests are mildly aligned.
But really, they are massively worse.
The question being tested is:
- Do Huawei devices have the capacity for adequate capacity
Not
- Are Huawei devices better or on par in terms of security compared to other vendors.
These are completely different questions with completely different methods of evaluation. And honestly, there is no control in the latter. To have a control you'd have to compare against normal operating conditions and at that point instead you really should just do a holistic analysis and provide a ranking. Which is still evaluating each vendor independently. _You don't want to compare_ until the very end. Any prior comparison is only going to affect your experiments.tldr: most experiments don't actually need comparisons to provide adequate hypothesis answering.
Let China sell their telecom bullshit to all the poor people of the world - they will learn hard lessons.
Obviously Windows will send more telemetry if telemetry it sent at all, because it's doing more stuff. Then again, Window's telemetry is nothing compared to what Huawei phones will send to the mothership, and Huawei phones are nothing compared to an Amazon Alexa. Not that any of that is relevant.
Maybe I'm being pedantic, but that doesn't answer their question.
Is this a good starting point?
Thank god we have the hardware and software vendors from a certain north american state, who take security very seroisly. Oh, wait ... /s
But imagine how bad your software has to be to not even be good enough to qualify as a pile of trash. Do not let terrible be the friend of bad.
RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do.
To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
[1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now.
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
> "AMERICAN AND BRITISH spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys used to protect the privacy of cellphone communications across the globe, according to top-secret documents provided to The Intercept by National Security Agency whistleblower Edward Snowden."
Dunno if that is still the case though. However, cell phones as secure communication did not use to be the case.
You would probably want to communicate with encrypted data traffic device to device.
BlackBerry got some market share for promoting their encryption.
Of course the encryption was complete junk, possibly worse than junk because of the false sense of security, unless you were an enterprise customer.
https://www.theregister.com/2016/04/15/canada_blackberry_wat...
Consumer-to-consumer BB messages were not E2E encrypted, but if you had a BES connected to your (on-prem?) Exchange server then everything with-in your company was wrapped in a key unique to your organization.
Further, I'm not sure if telcos could read the messages either: the bits were routed through RIM's central servers. For evidence of this, several countries made deals for access to the bit flow under threat of banning the service:
* https://www.wired.com/story/blackberry-india/
* https://www.theguardian.com/world/2010/aug/07/saudi-arabia-d...
All you need is the probe side of a tone generator and you can listen to analog phone conversations in progress with no additional configuration or hardware.
Digital test systems (I don't know what they use now; back then the venerable T-BERD 224 was the standard tool) can decode a single DS0 out of a larger multiplexed circuit and play the audio back and usually allow you to insert audio into a channel. That's normally what was being used to isolate a fault at one or more of the mux/demux/translation points.
* Someone tried to carjack a friend while he was suspended in the air in the bucket of a bucket truck, making a repair in a splice case[1].
* Another friend was making a repair in a bad part of town, and while doing some work in junction box (larger, ground-based version of a splice case,) a drug addict hobbled out of a nearby house and asked him if he was with the phone company. When he replied in the affirmative, the drug addict asked him to call 911 as one of his compatriots was ODing.
... etc...
I did get to help another service provider recover from a tornado by physically removing mud and debris from their equipment over the course of a few days and powering it back on. It almost all worked, with a few parts swapped out. I wrote about that one[2].
*Edit* I forgot I have one good CLEC war story. I wrote a test system that ended up calling 911 several times and playing a 1 kilohertz test tone at the 911 operator until they hung up. The test system was meant to troubleshoot an intermittent call quality issue that we were having difficult isolating. It consisted of a machine with a SIP trunk on one side and an analog telephone on the other. It would call itself repeatedly, play the 1k test tone to itself, and look for any audio disturbances, and record a lot of detail about which trunks were in use, etc., when that occurred. That all worked fine. The problem was the telephone number for the SIP trunk, which I remember to this day (20 years later) - 5911988. Every once and a while, when calling the SIP trunk from the analog line (this thing made thousands of calls,) the leading 5 wouldn’t get interpreted correctly, and the switch would just process the subsequent digits… 9, 1, 1 - as soon as that second one was processed, it sent the call to the local PSAP. After a few days a police officer showed up and asked us to please stop whatever it was we were doing.
0 - "not at all"
1 - in the US, anyway, these are the black cylindrical objects you see suspended from cables strung along utility poles
2 - https://marcusb.org/posts/2023/11/a-real-life-disaster-recov...
Encryption between tower and device were particularly weak in 2G and 3G days, but since 4G things have been a lot better. 2G's continuing existence remains a security risk, which is why Google Pixels have a toggle to turn it off, and iOS disables it when you enable lockdown mode.
Do not use SMS or non-E2EE RCS for anything you wouldn't shout at a random telecom engineer or passing police officer.
Cell towers (BTSs and eNodeBs) do indeed have unencrypted access to the data passing through them. They're owned by the operator, this is fine.
An attack on SIM card keys would let anybody listen to traffic going over-the-air or impersonate a cell tower. All you need is the keys and some radio equipment to receive the traffic.
Also, symmetric algorithms are quantum safe :)
But yes, I also wish that in 2025 we'd at least support ECC, which most smart cards should support natively at this point.
> To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
If you can't trust your SIM card vendor, you're pretty much out of luck. The attack vector for an asymmetric scheme would look a bit different, but if you can't trust the software running on them, how would you know if they were exfiltrating plaintexts through their choice of randomness for all nondeterministic algorithms?
The former is a true NOBUS, the second one is not (though you're right that governments would probably treat this as one).
The "NOBUS vulnerability" thing is especially silly, since the root of trust of all these systems are telecom providers. You don't have to ask if your American telecom provider is "in cahoots" with the US intelligence community; they are.
Who said anything about American telecom providers specifically?
> If you have the ability to distribute keys directly, asymmetric cryptography adds complexity without much payoff.
It's hard for me to believe that a symmetric key, touched by at least three systems (SIM card, operator HSS, SIM manufacturer), the former two of which can't be completely airgapped for obvious reasons, with no ability to rekey, is more secure than a key that is physically unable to leave a single device.
With a TLS-like system, you'd have to somehow hack every single SIM card to get anywhere. Hacking the manufacturer wouldn't help unless you could make them flash custom software that would exfiltrate the keys, and the consequences of an operator hack could be contained by revoking an immediate certificate and generating a new one, presumably from the operator's root cert, sitting somewhere safe in a completely airgapped HSM.
I saw numerous security issues, and when I brought them up, with solutions to improve the service for customers, I was informed the the company would lose money.
Scammers are big customers for telcos, and when they get caught, and banned, they come back again and pay a new connection fee and start the cycle again. Scammers also enable feature upselling, another way to profit from not solving the problem.
If it were a public/private key pair, and you could generate it on the sim card during manufacturing, the private key would never need to be anywhere but the sim card. Maybe that's infeasible because of seeding, but even if the private key was generated on the manufacturing/programming equipment and stored on the sim card, it wouldn't need to be stored or transmitted and could only be intercepted while the equipment was actively compromised.
Even if SIM cards were to feature an asymmetric private key: What would you do with it? How would you look it up, and what would you use it for? There is simply no provision for end-to-end encryption in the phone network at the moment.
If there were, it would be a different story, of course, but I doubt that will ever happen.
the data in transit is encrypted beyond anything the ISP has control over, so if the ISP provides lawful intercept they have fulfilled their obligation to the TLA because they let them see the data. it's not the ISP's fault that you and I encrypted the data. this isn't TLS encryption.
if that's not clear enough, then someone else will have to step in as I have taken as far as I can
For all person-to-person calls, my family and friends have long switched to FaceTime and WhatsApp, which are both encrypted. Why would I pay per minute for a less secure and lower fidelity (HD voice usually does not work internationally) channel?
That said, I really would prefer if the POTS were better secured, given that SSNs and payment card numbers are transmitted over it all the time.
Even if that were relevant (you can easily convert a block cipher to a stream cipher): It's absolutely possible to do key derivation for a symmetric stream cipher asymmetrically.
> the telco must know the secret key
No, the telco must not know the secret key if they're serious about confidentiality.
If it's derived from symmetric key material, you need to hack the manufacturer, card or telco once, and then it's over. As long as you can observe the over-the-air procedure where the session keys are derived based on the static keys, you can listen in on the entire session.
If it's derived from symmetric keys (both static and ephemeral), then if you are ever discovered and lose access to the operator's network, you can't decrypt any further communications.
Sure, it'll take decades to be fully rolled out, but that's true for every large-scale change. The real problem is that it's not in the interest of stakeholders to have end-to-end security.
5G has redesigned several core identifiers to make it harder for middleboxes to MitM/intercept traffic for a specific target. This has led to slowdowns in 5G rollout all over the world, as carriers needed their suppliers to figure out how to wire tap their customers now that they couldn't uniquely identify a customer by a static identifier anymore.
Carriers may have the best intentions for the security and reliability of their customers, but they're legally obligated to deliver plaintext dumps of phone calls on their network somehow. Same goes for other unencrypted side channels such as SMS.
If 6G redesigns the entire network to be fully E2EE, it's essentially illegal to roll out as a carrier. This isn't an engineering problem as much as it is a legal problem.
There are also financial challenges in a secure system. You need to know who to bill for long international three-way calls. That sounds easy, but because of backwards compatibility and many different ways to do roaming, doing billing for mobile phones is an entire industry in itself.
> You seem to be ignoring (or disregarding without explanation) similar engineering feedback
You mean the other "Bellhead" comments explaining why it's technically impossible to do something on the POTS that's been solved in OTT VoIP for years, like real-time end-to-end encryption using block ciphers etc.?
Yeah, I do discount confident statements declaring something technically impossible when I've been happily using such a system for the better part of a decade.
If we can encrypt basically every HTTP request on the Internet, surely we can encrypt a few phone calls too?
But the main problem is not technical, but that stakeholders don't want to anyway (lawful interception etc.), so presumably nothing will change.
Again, you seem to not understand the performance requirements of real-time audio. The amount of data is tinry, but the latency (and particularly jitter) requirements are on a completelt different level than HTTP.
The added latency is probably undetectable, and unless the CPU is at capacity, there’s no extra jitter either.
I'm really starting to wonder: Did I unintentionally send some kind of bat signal through time, channeling Bellhead objections to the feasibility of VoIP that have been thoroughly and empirically disproven years ago when the POTS largely switched to NGN and IETF standards, and people around the world have moved on entirely to Internet-based OTT VoIP services?
No, they do, exclusively. LTE and beyond don’t even support circuit switched calls anymore.
Bellhead wasn’t intended in a derogatory way, just as a reference to the “Netheads vs. Bellheads” schools of thinking about networks.
I do have great respect for historical phone systems and the clever engineers making them work. In terms of absolute reliability, I think VoIP was indeed a step back (although I think that’s mainly due to modern engineering and QA practices than inherent limitations).
(from https://www.ericsson.com/en/reports-and-papers/white-papers/...)
Circuit switched fallback means falling back to 3G or 2G (or maybe CDMA) for voice calls; if such networks are no longer available in a given area, VoLTE is indeed mandatory if voice calls are to be supported. (Which is often mandated by regulations, so networks sometimes even block non-VoLTE UEs from attaching.)
And yeah, of course we're talking about a redesign. If we were content with the status quo why would we be here?
https://securitycryptographywhatever.com/2024/04/30/stir-sha...
This feels like the obligatory XKCD comic[1] when in reality there isn't any secretive key extraction or cracking...things are just sent unencrypted from deeper into the network to the three-letter-agencies. Telco's are well known to have interconnect rooms with agencies.
Maybe these connections are a requirement for their permits in the first place. Who knows?
Not a requirement, but if for some reason you don't do the Right Thing that the NSA wants, oh dear your CEO goes to jail, he was a bad boy, look at all that insider trading. You'll do the Right Thing next time we ask, capiche?
Right next to the former https://de.wikipedia.org/wiki/Posttechnisches_Zentralamt
and https://de.wikipedia.org/wiki/Fernmeldetechnisches_Zentralam...
(similar to Bell Central Office/HQ)
hosting the Deutsche Telekoms early NOC and CIX.
There are also endless ramblings of some german blogger about how he has been sabotaged at the University of Karlsruhe, regarding very early development of encrypted digital telephony and data-transfer in the 80ies/90ies, by very incompetent and corrupted professors, connected to this.
Also related: https://en.wikipedia.org/wiki/Crypto_AG
https://en.wikipedia.org/wiki/Operation_Rubicon
https://en.wikipedia.org/wiki/Maximator_(intelligence_allian...
We're all friends, listening in on the party line :>
Freeswitch used to have a strong community spirit.
Things all changed since they took a more agressive commercial turn, a couple of years ago IIRC.
Since that point you now have to jump through the "register" hoop to gain access to stuff that should be open (I can't remember what it is, IIRC something like the APT repos being hidden behind a "register" wall, something like that).
I don't want to "register" with a commercial company to gain access to the foss community content. Because we all know what happens in the tech world if you give your details to a commercial company, the salesdroids start pestering you for an upsell/cross-sell, you get put in mailing lists you never asked to be put on, etc.
The team behind Matrix.org talked about a similar problem in one of their FOSDEM’25 talks: commercial vendors free loading on development.
Or indeed if they wanted to be compensated, they could have moved to an open-core model.
It was their decision for many years to keep the majority of the project as foss. IIRC there were only ever two commercial optional licenses, one for the G.729 codec and one for something else. Everything elee was foss.
They could have sold licenses for this that and everything else, but it was their decision and theirs alone not to.
I don't know what kind of community spirit you should expect for a project maintained by a single company like this.
It doesn't cost them anything metophorically or physically.
Updating the APT repo is a CI/CD script away. No doubt they do it for the commercial side anyway, so the tweak in the CI/CD is probably no more than a couple of variables.
And open-source projects can usually get freebies from everything they need. So there's unlikely to be much if anything in terms of actual hard-dollars expense for running the repos.
In reality that's really no different than the pre-internet age. If you don't want your stuff intercepted, you need to encrypt it by means that aren't trivial to access electronically for a major security apparatus. Physical notes, word-of-mouth, hand signals, etc.
Also, you need to be ready for the consequences of what you say and do online should a state actor decide to allocate the resources to actually act upon the data they have.
Lets not even talk about the mess of MF Tandems or almost every carrier barebacking the web by slinging raw unencrypted UDP SIP traffic over the internet...
It is possible to build secure systems in this space, but instead we have almost every major telecom carrier running proprietary unmodifiable platforms from long dead companies or projects (Nortel, Metaswitch,etc) and piles of technical debt that are generally worse than the horribly dated and unpatched equipment that comprises their networks.
When I asked a popular VoIP carrier about this a while back, they argued that unencrypted connections were fine because the PSTN doesn't offer any encryption and they didn't want to give their customers a false sense of security. While technically true, this doesn't mean we shouldn't at least try to implement basic security where we can - especially for traffic sent over the public Internet.
It'd be lovely to see some nations of the world pour some serious money into the various Linux Foundation (or other open source) telco & cellular projects.
Maybe the money should have more strings attached, be attached to grant proposals, whatever.
I don't see that that is an important or clarifying distinction. Governments should be directly helping, with money, somehow. Collectivizing the investment is better returns and far better outcomes, open source is the only way you're going to avoid risking your investment in a single company that may over time fail. Having your nation take its infrastructure seriously should be obvious, and this is how. And I disagree that good things only happen at companies. The post I was responding to stands as incredibly broadscale evidence that that often doesn't happen.
Hiring an outside company to do contract work leads to longer term maintenance issues where they disappear after the contract completes. It would be better to have individuals from a distributed set of organizations all collectively pitch in to do maintenance. This is how the Linux project is organized and it's very successful. While this is understandably unlikely to happen for smaller projects I think that just means it's important for projects to be created and maintained by larger collectives. Again, this is a common trend you see occur.
Is that not a kind of business/enterprise thing?
"Telecom" to me is like a network core equipment and radio towers - https://www.cisco.com/c/en/us/products/wireless/pgw-packet-d...
The "everything sucks and there's no motive to fix it" was a synopsis because, frankly, those conversations get really hard to follow if you don't know the jargon. And I didn't feel like trying to explain it poorly (since I don't understand the space that well, myself), so I left it at what I wrote.
(I didn't expect Hacker News to notice my blog at all.)
[1] - cape.co
"hey you who needs privacy, here's something that somehow costs even less than the ones selling your data"
Your blog actually gets posted somewhat regularly [0]. I actually remembered it, because it’s one of the rare cases where I like the "cute" illustrations.
There's just no way it can be insecure. Right.
Security in the telecom space has been a point of priority for the past couple of years and things are improving, but there are decades of legacy hardware, software, firmware, and network designs to cover for.
I doubt anyone is running standard Freeswitch in their telco networks, but the problems Freeswitch has as an aging telecom product with a history of not looking for security as much as one might expect those are all over the place.
It's very nice that the author spent their free time looking at code, found a bug and reported it -- I don't want to discourage that at all, that's great. But the fact that one maintainer of one piece of software didn't bow and scrape to the author and follow Security Industry Best Practises, is not a strong basis for opining that "Telecom security sucks today" (even if it does)
If someone came to you with a bug in your code, and they didn't claim it was being actively exploited, and they didn't offer a PoC to confirm it could be exploited... why shouldn't you just treat it as a regular bug? Fix it now, and it'll be in the next release. What's that? People can see the changes? Well yes, they can see all the other changes too. Good luck to them finding an exploit, you didn't.
The same thing happens in Linux distros. A security bug gets reported. Sometimes, the upstream author is literally dead, not just intransigent. If you want change on your own timeline, make your own releases.
Edit: 468 according to Shodan. I'm wondering if senddirectorydocument gets used at all by the XML RPC module.
curl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}"
Any ideas on triggering it? I imagine if we get a PoC that at least causes a segfault or whatever, they will be more likely to do a security release. $ ./test3 # see above
<HTML><HEAD><TITLE>Error 408</TITLE></HEAD><BODY><H1>Error 408</H1><P>Problem getting the request header</P><p><HR><b><i><a href="http://xmlrpc-c.sourceforge.net">ABYSS Web Server for XML-RPC For C/C++</a></i></b> version 1.26.0<br></p></BODY></HTML>
hmmmMany a "bulk SMS" provider in places like the richer carribean islands, and Indonesia that do a lot more than send spam.
So, it is old. 2G was designed in the 90s.
I don't really know what people expect? I'm just happy it works at all, lol.
Today's CAMEL (MAP and CAP) signalling is an evolution of the ISDN signalling which traces it roots back into (amongst others) the SINAP signalling protocol and the SS7 network stack from even before that.
SS7 is early 1970s stuff. From a more innocent time.
Any business with a PBX that wants to do more than just basic call routing and PSTN connectivity is likely using third party tools. And a significant number of those tools are built on FreeSWITCH, Asterisk, or similar.
Major carriers are like Vodafone, T-Mobile, O2, Telia etc :)
It's old but there's no reason to believe things have improved as there are zero incentives to. Also, software security vulnerabilities are only part of the problem - the other part is that telcos willingly outsource control and critical access to the lowest bidder: https://berthub.eu/articles/posts/5g-elephant-in-the-room/
So obviously relying on browsers is not enough, but a nitpick. The article links to a stackoverflow which actually notes browsers support a lot more.
Browser Address bar document.location or anchor tag
------------------------------------------
Chrome 32779 >64k
Android 8192 >64k
Firefox >300k >300k
Safari >64k >64k
IE11 2047 5120
Edge 16 2047 10240
"potentially thousands of telecom stacks around the world that SignalWire has decided to keep vulnerable until the Summer, even after they published the patches on GitHub."
1) To be slightly annoyingly contrarian, there is money to be made in secure telecom; Skype founders made a bundle, no?
2) This article conflates freeswitch with major telecom carrier infeastructure. My impression is that 30+% of the problem with security is not technical but economic. Carriers outsource a ton of their operations, effectively outsourcing most efforts to care about security... which never helps security posture unless the outsourcer considers their core value proposition, which they generally don't, instead pushing themselves as a cost/capitalization play.
3) No discussion of Matrix here as where things are headed, security-wise? https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/
most of them - if not all of them. This article is from 2021:
From the same author (that is to say, from me): https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
We as an industry keep poking each ourselves in our collective eye with a sharp stick, wondering why it hurts.
I get why nobody should use C for security sensitive code now, but in 2006 the options were very limited.
They see themselves as the wire, and thus completely incapable of being targeted by hostile third parties.
Non exhaustive list of problems I have seen:
Credit cards stored in plaintext on the carriers wordpress website. esxi and drac ports publicly available to the internet, not patched. inbound authentication not dropped by core infrastructure, log files just filling up with brute force attempts (often successful) Software vendors not implementing carrier network standards and telling everyone they know better. tech support opening socks proxy ports for technical support reasons and then leaving them open, where they get abused for netflix traffic. Field techs running around with core infrastructure passwords written on their paperwork Vulnerable hardware remaining unpatched and available to the internet for years - particularly fortigate stuff. Technicians building unencrypted pptp vpns on client infrastructure and leaving them open for years.
It doesnt surprise me that freepbx/asterisk etc are full of issues. They only get yelled at when they push a change that knocks some eccentric sip config offline, no one cares if they maintain vulnerable code as long as it works. Doubly so because theres a cottage industry in locating and using vulnerable SIP credentials for fraudulent phone calls.
I once got a ticket from T-Mobile (US) asking what "AWS's best practices were around security patching. How long should we wait?"
A week later they admitted to an enormous data breach
I'd say I switched phone carriers after that, but after working in the ISP market I already knew they were all absolute clown shows where all the money only went to C-levels and not infrastructure or security
Rust only fixes the memory safety issues. It doesn’t fix bad software design, the problem where we have to trust other companies to keep their security issues under control (eg. Cisco), and it can’t undo bad decisions that have become industry standards (eg. SS7)
Allowing any random bozo to connect to the network's trusted center was a bad decision.
If the regulatory mandate to allow interconnection had also mandated the development and usage of a secure protocol for that interconnection, we'd be fine. But it mandated the opposite. Politicians got us into this mess, not programmers.
I don't have a lock on my mailbox. It is bad that the "low trust" internet overflows into my everyday life. I would rather that there was some separation of telephone calls, local community and banking etc from the lawless voids, than normalizing all these scams.
Telephone scam calls are mostly an internet problem.
I do have a lock on my mailbox, but it has to adhere to the USPS skeleton keys (which have been leaked and are exploited by thieves). Another example of bad design, or at least design that wasn’t able to withstand reasonably foreseeable changes to the operating environment.
Yes, insecure, but needed. Unless you want to shut down 2G and 3G worldwide. It is happening, slowly.
The FreeSwitch stuff? Telcom buy from vendors like Nokia, Cisco, Ericsson, Huawei where they can't see src anyway.
Anyway, it's insane that we have a mathematically-proven secure kernel, we should use it! Surely there's a startup in this somewhere..