Hacker News Reader

Comment by phkahler | Hacker News Reader

The problem here is the ability to spoof caller ID. This should not be possible. Regulations set up the phone system, regulations need to make this change. I don't care what excuse anyone has, don't care about your stupid PBX or any of that. Caller ID should be mandatory and reliable.

Having said that, always assume someone calling you is a fraud. If your "bank" calls you, tell them you'll call back and don't call a number they provide over the phone or in caller ID. If you can't find a reliable number to the bank, drive over there. The bottom line is that you can't trust anyone who calls you.

View on HN

The problem here is the ability to spoof caller ID. This should not be possible.

Think of incoming CLID in the same way that you do email From: addresses. Often and easily faked. Funnily enough both my office PBX and SMTP daemon check incoming CLID/HELO and drop attempts to spoof their own identity. Its not a particularly sophisticated protection these days but is one of many, many rules. Actually, now I come to think of it, my firewalls also check for inbound IP spoofing on their own IPs.

As the OP stories highlight, your mental firewall must make you bail out when asked for your PIN, regardless of how legitimate things sound. The only thing that should ever request your PIN is a machine that you have stuffed your card in first. I'm pretty certain that CVV requests should also only ever come from vendors that you are buying from, not your bank.

The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN. Which nobody wants to pay money to completely replace.

> The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN.

Why not? That's how it was done for email. SPF doesn't prevent interoperability for sending domains that don't use it or recipients that don't verify it. What it does is inhibit forged messages from a domain that does use it to a recipient that does verify it.

Then the more senders who have an SPF record, the stronger a spam signal it is for a domain to not have one, and the stronger the incentive gets for senders to use it. It's already in the recipient's interest to verify it when it's used.

They could even use DNS for this exactly like email. Create a lookup zone equivalent to in-addr.arpa but for phone numbers.

Because it's a huge installed base of non-upgradeable equipment that is 15, 20, 25 years old. People doing oldschool SS7 telco stuff are just not going to upgrade. They'll sue their upstream carriers if they suddenly cut them off because their new re-implementation of SS7 is incompatible with their old gear. I'm a senior network engineer for a mid sized regional ISP, and encounter this shit on a fairly regular basis.

It is not as simple as getting everyone who runs public facing smtpd on the Internet to upgrade their software and practices. Telco and PSTN phone stuff is the very opposite of being up to date and continually evolving best practices for security.

It isn't the upstream forcing the upgrade. It isn't forced at all. You can keep using your old equipment as long as you want. But there would come a point that enough people are using the new protocol that recipients start auto-blocking calls from anyone who doesn't use it.

You may not even have to upgrade the old equipment. For an out of band protocol, the upstream may be able to implement it for you.

When you get a scam call, you know that somewhere there is a company that got paid for that call, because telcos -- even and really especially scummy shady scam-enabling telcos -- don't offer access to their network for free out of the goodness of their hearts.

Turning those companies into smoking holes in the ground doesn't require anyone to upgrade their equipment. All it takes is willingness on the part of lawmakers and regulators to track them down and make them regret their business practices.

Cut them off unless they upgrade, their upstream probably has that option in the agreement anyways. Ptsn should just die. The technicians and customer service are so incompetent that every day I had to call to get a line disabled at the switch because it got re-enabled. After a hundred days in a row I finally just shorted the damn line and problem solved.

True, but you can use your firewall for SIP'n'RTP or IAX2.

Creative use of firewall rules can be really powerful. For a very simple example: block VoIP from AWS's address ranges (serious gain).

A classic response for anon calls in telephony is to make the caller record a short identifying message and then play that to the potential recipient. The potential recipient then decides whether or not to accept the call - your staff (family, whatever) become the firewall. Remember that calls are billed to the caller by the terminating provider so this is OK (caller pays).

Those are two simple examples of using IP and humans to firewall telephony. Just because telephony is a bit crap on the identification side does not mean that you can't deploy lots of other weaponry to keep yourself safe. If you look deeply into SIP and IAX2, you get loads more options as well.

A better analogy that I use (especially with nontechnical folks) is the return address on an envelope.

You can, technically, write anything in it and there’s no way to guarantee it’s authentic.

In email the From: address rarely delivers the mail. From: and To: are the ones that you see in your mail client and correspond to the addresses on the letter within.

For example here are some headers from some spam I received:

  From: "Jeremy Adamson" <jeremyadamson@illusion24.com>
  Reply-To: "Jeremy Adamson" <jeremyadamsonr@yahoo.com>

From: is what I see in my client and Reply-To: is where a reply would go to.

This one is much better, note how I'm BCCd and To: is complete bollocks:

  Reply-To: dr.ahmed.faruk@outlook.com
  From: Dr Faruk Ahmed <dr.faruk.ahmed1@gmail.com>
  Subject: MANAGER AUDIT AND ACCOUNT DEPT
  To: undisclosed-recipients:;
  BCC: <gerdesj@blueloop.net>
  Return-Path: dr.faruk.ahmed1@gmail.com

Given that Reply-To and Return-Path are in different domains, where would a reply go to?

What about an out of band verification by the carriers?

Basically a large registry. When I call someone I tell t-mobile who I'm calling, and they register it. Then on the receiving end Verizon checks with T-mobile or a central registry, and says yep James's number is calling this number. Then it marks it as a verified call.

Bear in mind that it is not in a carrier's (financial) interest to drop a call. Carriers are not required to verify CLID either.

There are lots of good things that telephony could be required to do but they are not and they wont.

iOS/Android could do something like this. You register your number with Apple/Google and link your account with them. When you call someone you set a field on your account that you're calling someone. When the person who you're dialing gets rung, their dialer can look up Apple/Google and see if that number was indeed calling them, and add a "verified" checkmark to the call.

This leads down a privacy/metadata rabbit hole, but there are probably ways to make this a lot better. In any case, the phone OS can do some out-of-band signaling and just avoid dealing with the carriers altogether.

Although if you're doing all that then why not just make a call using voip...

Curious: how does the PBX verify caller ID? Do you know how it works in practice?

It doesn't actually verify it, all it can do is read it. Just like email. When the PBX is told that the caller is say 01460223344 (I'm in the UK) then it would infer that the caller is from Crewkerne in Somerset due to the 01460 which is a designated area code. It may also be able to look up the whole number and infer a source.

However, just like email the CLID can be trivially faked and just like email, the lookup in your contacts is then wrong and potentially dangerous. In the case of telephony, if you subscribe to the BT service (I presume it still exists) that will return a name given a CLID (just like DNS for a price!) then you may end up with completely the wrong thing on your display.

Just to re-iterate the point: a PBX/phone/whatever cannot ... CANNOT ... verify CLID (Calling Line IDentification) it can only show what is presented to it.

Remember this, please: CLID is nominally under the control of the caller and could also be changed in transit. It should absolutely NOT be considered authoritative in any way.

It's not quite "Just like email" because email has systems in place to authenticate this, while phone systems do not.

https://en.wikipedia.org/wiki/DMARC

Have you ever tried to implement DMARC? DKIM and SPF are OK but DMARC breaks mail lists. Yes there are ways to mitigate but it might not be worth it unless you also do DNSSEC as well. Well actually I believe that every little helps and use every weapon available.

I do think that the analogy works really well. PBXs can have quite a few weapons of their own to attempt to authenticate callers. For example you can pass "anonymous" calls to a dialplan that gets the caller to identify themselves and then play that to the recipient who then gets to allow/disallow the call - basically make the (human) recipient part of the firewall. Also, PBXs that deal with VoIP can use IP rules just like a firewall to make decisions on what to do.

Traditionally, "telephony" and "systems" have been considered separate. Personally I'm a sysadmin AND telephony bod with around 25/15 (respectively) years experience. My PBXs (generally Asterisk with FreePBX) have quite a few sources of intelligence about what is inbound, beyond CLID. I also look after quite a few email systems, often fronted by an Exim MTA with an attendant rspamd or spamassassin (int al).

There is a new standard called Authenticated Received Chain (ARC) designed specifically to address the DMARC authentication failure issue caused by mailing lists. Basically what ARC does is to preserve SPF/DKIM authentication results, and use them to override DMARC authentication result when deemed appropriate. There is a Quora post here for a more detailed explanation: https://www.quora.com/What-is-Authenticated-Received-Chain-A....

I haven't set it up, but how does it break mail lists? Do you mean like using third party providers to send emails with your own domain in the From address?

It is (or was) common for mailing lists to keep the From header when forwarding mail to a list. The envelope sender is commonly changed to refer to the mailing list for bounce processing, and often a mailing list footer is added, sometimes the subject is adjusted and other administrative headers are added.

Changing the subject or adding a footer will almost always break the DKIM signature, and DMARC won't like it anyway, because the From address and the envelope sender don't have the same domain (alignment). This makes it pretty hard to use DMARC for a public domain.

It's not so bad to use it for a corporate domain, and it helps a bunch if your domain is being used to source phishing; except that people still think you sent it when it comes from admin@yourlocaldentist.crappyhosting.example.org which is clearly some ancient web mailer script that was compromised 20 years ago, but still remains online. (I'm totally not bitter!)

My domain, lolware.net, has a total of three email accounts. I'm usually happy to move and break things because it's largely a personal playground. For example, my website's SSL ciphers have frequently veered into the "not many browsers support" solutions.

I cannot properly enable DMARC. I have working SPF and DKIM on everything I send, but as soon as I enforce it, people stop getting my email. The sticking points are mailing lists, and anyone with a forwarder. I've been on this merry go round a few times. If it's this bad on this personal domain, I'm a long way from considering it in a business.

There is no way to fix the ability to spoof caller ID with the way SS7 is built. Not without breaking functionality to something like 85% of the installed base of PBX and phone switch equipment, most of which is anywhere from 10 to 45 years old. The legacy telco SS7 phone system needs to be burnt to the ground and rebuilt, but it never will be, because people have moved on to friend-opt-in based message platforms like whatsapp, signal, telegram, facebook messenger, and the domestic chinese equivalents (wechat etc).

Compelling telcos to do that is the regulator's job.

Not sure about the US, but in most of the rest of the world regulators come up with new rules and regulations requiring some form of network upgrade all the time – SLAs, connectivity and routing requirements, legal interception, data residency, etc.

And telcos have no other way but to spend billions to protect some monopoly or enable more surveillance power for the governments. It's a matter of priorities, really.

I just want the major cellphone companies numbers to show up correctly and everything else can be ???. That does not require fixing all these other systems.

Exactly, If your provider can't be certain that the number is real (i.e. they generated it themselves or it came from a trusted/liable source) then they shouldn't be charging for it and held liable if they allow a spoofed number for fraud. Maybe that would be the mean the end of caller-ID and associated fees, but if I'm not sure that it's useful today with the level of spam. If someone spoofs your ph# to make 5000 spam calls, I guarantee it's not useful to you.

Find another in/out of band way of providing caller-ID services.

How exactly could they do that for calls originating outside their network? Most spammers are using VoIP, not cell phones on major US companies.

They could not fix it. However, it would be a big value-add to me if, say, the big 4 US carriers could add an out-of-band security check and block calls to their networks from numbers they control but which are spoofed.

I get way too many calls from area codes and prefixes I recognize. This would help me get some of that back.

There are legitimate use cases like Google Voice for sending caller ID that another carrier owns. Despite that, a basic authorized users list would be an easy fix, doubt that'll ever happen though. Look at the mess that LRN and CNAM data are, providers will nickel and dime for access to data that doesn't cost much to maintain...

Google Voice could A join the system or B have ??? as their caller ID either one would be useful. Again, they can say whatever number they want as long as I can opt out and block unknown numbers.

However, the current system is largely useless when you get spoofed calls from numbers you recognize.

they can't, because as things currently exist they have to trust the caller ID data in the SS7 links coming from other wholesale carriers where the calls are coming from. possibly several hops away from the grey market voip sip trunking providers.

They know who to Bill for the call. Fix the rest. I don't care about excuses for this.

Yeah, it's hard not to think that basically rebuilding the entire phone system would be a massive case of fighting the last war. People won't stop needing the phone system entirely but it becomes a piece of quirky legacy technology.

And probably just have to live with the fact that there will be situations where people are harder to reach quickly than they are today.

Rebuilding SS7 with new modern features, and making it talk natively to all the existing 10 to 50 year old SS7 equipment deployed in the world would basically be polishing the brass doorknobs on the titanic.

Agreed, caller ID should not be able to be spoofed. My rule of thumb is if it is important, they will leave a voicemail with a call back number. This screens out 90% of the spoofed calls I get. The visual voicemail is a nice feature too, I can immediately check the voicemail that is left and decide if I need to follow up, or if it is spam.

Yeah I get spam phone calls almost daily, and it's always from a local area code and ANI which I recognize as being from a nearby city. So, it _seems_ legit. But I no longer answer phone calls from numbers I don't already have in my Contacts... :P

One thing I hadn’t thought of until a friend who is a parent mentioned it, is that if you have a young child and that child is currently out of your sight you basically have to pick up a call from any possibly local number, it’s just too risky not to. I would imagine that accounts for a lot of the success of this strategy.

I inadvertently solved this by keeping my old, out of state number. I can pretty much block all numbers that match my prefix if they aren't in my contacts.

Any actual local number is always legit since spammers have no way of knowing where I actually live.

In my case I have a bit of an outlier combination so it never seems legit when I get a call from a number like that. Makes it easier to spot the spammers, however!

It looks like Canada is moving in this direction.

Here is a PR piece (by a telecom technology vendor) that explains that the Canadian telecom regulator will require non-spoofable caller id by March 2019 [1]. The technology is called STIR and SHAKEN. (That's all I know; I'm no expert).

The US FCC doesn't seem to be moving as quickly, if at all.

[1] https://transnexus.com/blog/2018/canadian-regulators-mandate...

> Having said that, always assume someone calling you is a fraud. If your "bank" calls you, tell them you'll call back and don't call a number they provide over the phone or in caller ID.

I did this to a student loan company. The caller ID was that of my parent's house, and the woman on the other end was incredulous that anyone would demand that she prove who she was.

And it turned out to be legitimate, incredibly, though I certainly did not think so at the time.

If you can actually identify the company or individual on the other end of a spoofed call, please report them to the FCC.

The problem is the lack of motivation: VOIP service providers aren't being smacked with multi-thousand dollar penalties per call when their customers spoof caller ID.

If Peerless Networks was starting at millions of dollars in fines fake IRS scams originated on it because there's no way for someone else to find who actually originated the fraudulent calls, you would be able to bet a farm that a concept of a fake caller ID coming from Peerless Networks would go away.

> don't call a number they provide over the phone

It's OK to ask for their extension. A lot of times you can't call the fraud department directly, but if you have their extension you can ask to be transferred to it. But yeah, always call the number printed on the card, not what they tell you.

Note that on many land-lines this will fail, as the calling party simply does not hang up, waits for silence on the line, then plays dial-tone down it. When you pick up again, it seems like you are connected to the exchange, but when they hear DMTF they just play ringing tones back at you, then pretend to answer as your bank and continue the scam. Bonus points to the scammers if they actually call the number you dialed and MITM the call for extra realism, only jumping in when you get transferred... ;) In fact, I bet you could program Asterisk to do this for you, or similar VOIP PBX software?

If only there was a way to register a Public Key that only a corresponding Private Key could use.

Won't this rapidly become beside the point?

With text to speech software becoming so amazing, see Google's Duplex, I'm not that concerned with caller ID and am massively concerned for aging boomers who will have to contend with nearly perfect speaking bots.

I did this to my bank. They called me, I told them that I'll not talk to them as I can't identify them and that I'll call them back in standard number. Bank was really not prepared for this. They blocked my card (call was about suspicious transaction that was ok) and the transaction. I called to unblock transaction, but card remained blocked. So I had to call again.

It all took precious time, they really should anticipate this more.

Speculating, but Would fixing that break things like dialing a local number which is answered overseas without a toll charge? Or is that separate?

If we make a regulation that requires protocols to change so that the caller ID to be unspoofable, we might as well also require to make it impossible to spoof an IP address or a sender email address...

I work for an ISP. We filter packets spoofing their IP source address.

SPF, implemented by most major email providers, helps to prevent FROM: spoofing.

Hell, I'm pretty sure our VoIP product drops external calls where the Caller ID matches one of its' own numbers.

These are problems we are solving. These are problems we should be solving in telephony too.

You mean like we are trying really hard to get everyone to use https and most people here would love some easy to use, widely adopted email signing? Yeah, that would be awesome!

Reply on news.ycombinator.com