Hacker News Reader

Comment by gerdesj | Hacker News Reader

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.

View on HN

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.

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.

> 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.

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.

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.

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).

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 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....

Reply on news.ycombinator.com