How does an SPSP client verify they are communicating with the intended SPSP server?

Protocol Design
1

From @adrianhopebailie on Wed Feb 14 2018 11:12:19 GMT+0000 (UTC)

@dappelt raised this issue specifically against payment pointers. Irrespective of what is done in the Payment Pointers spec to address it we should track this against SPSP too.

The following is an edited version of @dappelt’s issue with more general focus than just Payment Pointers.

Problem Statement

How can a user or an implementation verify that they are communicating with the SPSP endpoint of the intended recipient?

Example 1: Phishing techniques may trick a user into paying a familiar looking payment pointer, that resolves to a different SPSP endpoint that they expect. (Examples are homograph attacks and typosquatting.)

Example 2: Man-in-the-middle attacks may result in a sender being passed the incorrect SPSP endpoint URL when attempting to make a payment.

Phishing will likely become a bigger problem for Payment Pointers + SPSP than it is for websites.

In comparison, phishing websites require some effort to look convincing while spoofed SPSP endpoints can more or less simply copy the data from the intended SPSP endpoint. Phishing websites also need to come up with a believable reason why a user should enter their password and a second factor, which makes careful users suspicious.

Potential Solutions

EV Certificates (proposed by @adrianhopebailie). Upon receiving a given payment pointer for the first time, an SPSP client could prompt the user to review the certificate details of the SPSP server. Subsequent payments to the same pointer do not have to be reviewed again by the user.

@dappelt :

I don’t think EV certificates will solve the problem. It is easy to obtain fake EV certificates and they don’t help against phishing. Also, making EV certificates a requirement to run an SPSP server would hamper adoption, since they are expensive to obtain.

Another drawback is that a certificate is tied to the domain (i.e. SPSP server) and not to a particular SPSP endpoint. For example, if example.com is an SPSP hosting providing, the legitimate receiver $bob.example.com will have the same certificate as a spoofed receiver $b0b.example.com. And there are other problems with using certificates for this purpose. For example, if the certificate is renewed the wallet implementation detects that the certificate changed and gives a false alarm about a phishing attempt.

Warn/reject if SPSP URL contains Punycode.

The client software could legitimately reject that (internationalized) pointer OR give an extra warning to the user that it is being converted from an internationalized form.

@dappelt :

Showing a warning before displaying internationalized payment pointers does not help users of non-latin alphabets. Such payment pointers, no difference if legitimate or not, would always prompt a warning and quickly become ignored by users. In addition, users that send mostly to ASCII pointers would get irritated by such a warning when occasionally paying to a legitimate internationalized pointer. Either we support internationalized pointers or we don’t. Something in the middle doesn’t help either user group.

Picture in SPSP response.

For each payment pointer, the user could select a picture that must be returned in the SPSP response. A spoofed SPSP endpoint does not know the picture and, hence, a user could recognize phishing attempts (essentially what okta.com does to prevent phishing).

@dappelt :

However, I discarded this idea again since a user would need to remember too many distinct pictures (one for each pointer).

Secure payment setup as part of SPSP.

@dappelt :

I am currently looking into how a payment pointer can be tied to an SPSP endpoint on the protocol level. SPSP could be extended so that subsequent calls to the same payment pointer verify that both sides have knowledge of a secret. Such a secret would need to be established the first time a given wallet and SPSP endpoint interact. Phishing attempts fail since the spoofed SPSP endpoint does not have the secret. The name of the protocol I am looking into is secure remote password.

Copied from original issue: How does an SPSP client verify they are communicating with the intended SPSP server? · Issue #392 · interledger/rfcs · GitHub

2

From @earizon on Wed Feb 14 2018 14:52:11 GMT+0000 (UTC)

Just a “blur thought”. Public Key infrastructure is complex and it has never worked properly. The chain of trust is not trustable at all. I think one important use case of ILP could be to “replace” PKI. The idea is as follow:

Users who want to visit a web site have to pay a minimum quantity (maybe 0.1 cents of dolars) when login into the site. The web-site start offering content once they have received the micro(nano) payment (“a la letter-shop”). The initial payment establish the secrets to communicate client and server.

Change the flow visit -> pay, to nano-pay (login+AAA) -> visit -> pay.

It exists the possibility of cheating about the initial payment pointer but it will be really hard then simulate the real site (Google, Facebook, Amazon, …) after that. Users will notice immediately.

I guess is not big deal for final users to pay micro-quantities when login into a service if that makes their navigation safer. (Most probably the time spent now with PKI is much more expensive than doing an initial micro-payment)

1 Like
3

I think the way that GMail deals with email addresses is something we could take inspiration from. If you’re sending to an address, it’ll look in your history to show if you’ve sent there before (and show similar looking addresses). It also shows a warning when someone sends you an email from an address that has similar details but a different email address from one you know.

These would be wallet features rather than protocol changes but I think they can get us a long way. If you’re sending to your friend but you were given a fake address via a MITM or something, this would do a good job of catching it.

The riskiest part then would be entering a payment pointer you’ve never sent to before. We could mitigate that somewhat by creating a mailto-style uri format that would autofill the pointer (so at least you don’t get typo squatting as much)

The one part I’m not sure of a good answer to is the first time entry of an pointer that might be from a phishing site. But I suspect you could solve it with a wallet feature (i.e. flag pointer as suspicious and aggregate that data to help all users)

3 Likes