Deprecate http listener for external addresses

[lehnberg]

Deprecate http listeners for external addresses due to it being insecure and exposing the transacting parties to unnecessarily easy attacks.

Blocked until a convincing better alternative is proposed for transaction building.

---

Apr 02 2020 edit: Renaming and editing description and using to track for v4.0.0

[antiochp]

This may be a hard sell due to certs etc?

[rsoltanzadeh]

How about giving a huge warning whenever it tries to use HTTP and making sure the users understand the risks every time (prompting once or twice unless --no-warnings or similar flag is used) rather than enforcing HTTPS? Even if certs were easy and effortless to get, CAs still have to be trusted. While that is normally not a problem, it might be in crypto. It might give a false sense of security to users as cryptocurrencies are otherwise trustless (or supposed to be).

[lehnberg]

If we do not set a minimum standard of what is acceptable security here (and then raise the bar to that level), no-one else will. And default instead becomes what's the easiest and least effort-taking to support, regardless of what that means to privacy and security.

I personally think http should never have been allowed in the first place on mainnet. This is not the type of transaction method we want to be the lowest common denominator in transaction standard between businesses and their users. It kind of defeats the entire purpose of why you would use Grin in the first place, in my opinion.

@rsoltanzadeh I don't think HTTPS is optimal by any means. But I'd rather the problem be that users sometimes need to trust a certain CA for a cert's authenticity, rather than being at constant risk of being trivially MITM'ed and/or have their transaction slates passed around the net unencrypted.

[mcdallas]

I know that http is bad but from what I can tell from discord the vast majority of users use this method for transacting. With https anyone that wants to receive coins will have to register a domain and get a Let's encrypt cert that needs to be updated every 90 days. Do we want to make it even harder to transact with grin?

Imagine most pools/exchanges not being able to send payouts anymore, they will most likely stop upgrading their nodes to not disrupt operations.

I think that until a more user friendly alternative comes, http needs to stay (maybe with a big fat warning).

[hashmap]

Imagine most pools/exchanges not being able to send payouts anymore, they will most likely stop upgrading their nodes to not disrupt operations.

It could be solved by 2 https requests from the client side (can be done now) or invoice functionality (coming soon). To receive money one still need to have a publicly available IP which is a high bar for the most of users.

[mably]

Wouldn't it be possible to use self signed certificates?

[hashmap]

@mably It doesn't protect against mitm attack at all. Certificate is not an issue, the roadblock is domain name. However static ip is the biggest issue anyway for both http and https.

[mably]

Ok, it's harder to take over a DNS than an IP address, that's the idea?

And no free certificates for dyn IP addresses if I understand it correctly.

[mably]

Not directly related, but what if it could be implemented over Tor?

[hashmap]

No, self-signed certificate can't be checked against trusted authority, so if I intercept your traffic and sign it with my self-signed certificate your recipient can't tell the difference.
You can't get a free certificate for IP address atm and it's questionable in general, so it's cheaper/more secure to get a domain name. For dyn IP there are so many issues, most users can't even expose a port.
Tor should work, but it requires a manual intervention form a user and some technical skills.

[hashmap]

I think https server makes sense for business or advanced users (with static ip and domain name), https clients could be widely used to interact with such services. It's not hard to implement model where a "home user" only runs http client both for payment and withdrawals, perhaps we should standardize it and implement in the wallet.

[garyyu]

Related to https://github.com/mimblewimble/grin/issues/2224.

I would propose to have a transaction privacy enhancement solution, other than limit the transport methods.

[lehnberg]

@mcdallas:

I know that http is bad but from what I can tell from discord the vast majority of users use this method for transacting.

Yes exactly. This is the problem - it risks becoming a major issue for us. It would be unfortunate if Grin becomes known as the currency where funds just get stolen out of thin air as you try to make deposits or withdrawals. It should never have been supported in the first place on mainnet.

I think that until a more user friendly alternative comes, http needs to stay (maybe with a big fat warning).

It's also possible that as long as we allow this insecure yet comparatively convenient way of transferring, there will be no better alternatives. There will be little incentives to develop one or for users and exchanges to switch to it.

[0xmichalis]

I think that until a more user friendly alternative comes, http needs to stay (maybe with a big fat warning).

+10000

We should be cautious about breaking people now that the ship has sailed. Also, the UX needs to get better, not worse.

[rsoltanzadeh]

What about including symmetric encryption in HTTP transfers?

Alice: Bob, send me 5 grin. Code phrase: "make me grin again"
Bob: Alright, encrypted slate coming via HTTP right now!

[hashmap]

@rsoltanzadeh that's basically how TLS (HTTPS) works plus it includes keys exchange

[casey]

What about some form of public key + address scheme?

• Wallets generate a key pair and print out the hash of the public key
• Wallet URLs look like PUBKEY-HASH@DOMAIN or PUBKEY-HASH@IP-ADDRESS
• Connections are authenticated and encrypted with the key pair, so MITM attacks are not possible.
• To avoid having to implement an entirely new authentication and encryption scheme, key pairs could actually be self-signed certificates. (There exists at least one nice rust crate for generating self-signed certs.)

[rsoltanzadeh]

@hashmap the point was to not have to go through the hurdle of getting certificates, not that it's a better form of encryption.

Include symmetric encryption on HTTP transfers and release it quickly and work on a HTTPS solution afterwards? This feels urgent.

[garyyu]

@casey I'm interested in your proposed PUBKEY-HASH@DOMAIN/IP solution. Would you like file a PR for it?

[0xmichalis]

What about some form of public key + address scheme?

End users are still required to do port-forwarding in their routers and/or own domains with this approach, right? Creating an address-based scheme as a stopgap when TLS is already an option is likely going to distract both end-users and development effort.

A NAT-friendly tx building solution is going to be more useful IMO: mimblewimble/grin#1798

[casey]

@garyyu Unfortunately I have too much on my plate at the moment to submit a PR :(

@Kargakis Users would still be required to do port-forwarding, but they wouldn't be required to own a domain or get a cert. I would very much like to see a NAT-friendly TX solution available, most likely tor or a tx relay, but this might be a good option in the mean time.

[ignopeverell]

grumble grumble embed i2pd grumble grumble

[0xmichalis]

@ignopeverell instead of embedding i2pd, could the wallet just use an i2p client? It would probably be simpler to implement and release at the expense of not contributing back to the i2p network.

[ignopeverell]

The additional advantage with embedding i2pd, which I think makes it worth it, is that you get a network address. So that would solve multiple issues in one fell swoop (not to mention the privacy gains).

[lehnberg]

Better late than never, this was discussed during the Feb 5 dev meeting, and the following was agreed:

• Http command line send/receive to fail with a big warning and instruction to add --unsafe in the command.
• Send --unsafe -d http://.. executes, but also has a warning added.
• Fully deprecate http once there's a sensible path to do so.

[IstoraMandiri]

https is enforced
fully deprecate http

In some cases it might be ok to use HTTP; I don't think it should be discontinued entirely (if that's the suggestion).

• Two clients are on the same machine (sending to localhost)
• Two clients are communicating on a trusted network (e.g. VPN, VPC, LAN)
• You have some kind of proxy handling transport security somewhere else

[aleqx]

I'm late to the party, but I've been reading this thread with interest.

We must all agree that as great as GRIN is, the ease of use has been a turnoff. I for one learnt to respect (rather than ignore/reject) thy clueless folk -- they are the ones who add the necessary pressure to innovate, just like gamers basically pushed Nvidia to become the giant it is today. Grin most definitely needs a much more seamless and more reliable way of sending and receiving if it is to be more widely adopted.

At the same time, I fully agree with the security arguments. In fact, ever since GRIN has started being talked about more widely last year, particularly after launch this year, I've been amazed at how little public- and user expressed concern there is for security and the trivial-to-implement MITM attacks on grin tx's. I recall watching how after launch hoardes of miners were sending GRIN to IP addresses of new anonymous chinese exchanges over http, addresses given out on Telegram channels etc. Now we see a proliferation of public proxy services for dyn-ip wallets to receive funds. It's cringy and sets dangerous precedents. A secure, professional, non-hacky solution is needed or else GRIN risks not being taken seriously long term, after the hippie phase subsides.

At first I was going to suggest "just embed openpgp" and self signed certs (basically @casey's proposal) but I think @ignopeverell's suggestion is the simplest and best, and also addresses ease of use. Was there any progress on this?

Genuine question: Why isn't this top priority? I agree with @hashmap that the longer http:// is allowed to be used, the more the people will get used to it as the norm, making a shift to a proper solution more difficult (and deprecating things abruptly is never a good idea, especially in this context with exchanges floating around).

While GRIN has stated from the very beginning that it's just an experimental tech, I think we have to agree that the users' perception is sometimes more important than truth (like in politics, bleh) ... if they think GRIN is the next BTC and really want ease of use, security, value, etc, then someone will come up with solutions to meet that pressure. GRIN may very well become vital despite initial intentions.

p.s. Long term ipv6 may make send/receive easier still.

[yeastplume]

@aleqx There's work currently underway on i2p support, which we think will be a long-term solution. I agree the current situation isn't ideal, but MITM attacks on slates aren't quite as easy as you suggest. Most of the info on slates (the transaction info) is considered 'Public', and due to the Schnorr signature scheme nobody can really modify much within the slate without knowledge of the private keys. There is the possibility of leaking total transaction amounts, however, which I agree isn't great.

Have a few ideas on protocols that might make transacting easier and more secure, but would like to see the wallet subteam formed first to have these explorations.

[aleqx]

Agreed. I was referring to intercepting and impersonating (no relaying) rather than MITM. Simply put, right now whoever gets the slate gets the dosh (intercept the sent slate, finalize and return receive slate). Plain http makes that scary. A disgruntled sysadmin/ISP employee/etc sitting in the comms chain could once decide to just receive the tx themselves and say thanks very much.

Very glad to hear i2p support is underway. It'll be a challenge to make Grin both easy to use and secure but nobody said life is easy.

[OctoberSouth]

Error reporting using grin-wallet send -d "xxxxxx" 0.001 ,log is (error grin_wallet_impls::adapters:http - performing version check (is recipient listening?):request error:cannot make reclsed),why is this

[lehnberg]

This ticket has been refined and repurposed to comply with the target of 4.0.0 as discussed in the Mar 31 dev meeting.

[GHLover]

Whatever you do please do not deprecate HTTP for localhost listeners at a minimum. Currently, I like the ability to create proxies in front of the internal HTTP listener. Please also do not disable sending to an HTTPS address.

[GHLover]

Also, IMO, any requirement in the future of Grin such as the necessity for i2p or tor daemon should be part of the single Grin binary.

Requiring users to setup Tor or I2P just to utilize Grin will guarantee that Grin never has a use-case. Barriers to entry should be decreasing, not increasing, IMO.

[aleqx]

I would also like to keep http for localhost as I want Apache in front to reverseproxy and handle https there more easily.

Barriers to entry should be decreasing, not increasing, IMO.

I've been saying the same for a while. I'm sure the devs are well aware of the aspects regarding usability. Sadly, Grin was launched in a state usable only by experts (give or take) and thus has set an undesired tone and impression. More than a year later it looks to me there adoption and usage is decreasing, that is once you filter out the fanatics -- those who claim Grin is the next BTC or those who claim "BTC also needed years to catch on" (missing the point that there was no precedent or alternative for BTC).

I would love to see more work towards user-friendliness and GUI wallets rather than more under-the-hood bits that contribute little to nothing to improving usability and adoption for average users.

[lehnberg]

Deprecation message was introduced as part of #423, due to be released as v4.0.0 in 30 days time. Closing this issue.