Add wallet transfer support for hip-0002 #400
Conversation
app/utils/wellknown.js
Outdated
| rejectUnauthorized: ca, | ||
| }; | ||
|
|
||
| const req = https.get(`https://${host}/c${token}`, options, res => { |
There was a problem hiding this comment.
Yes. Make a bug just make a commit and change the wellknown address validate path to daneOrCa.
There was a problem hiding this comment.
@Falci Sorry for my wrong operation. I clicked the resolve conversation. Seems the comment was removed here. I mean I can make up to feature on the setting page.
- Config the strategy to validate well-known address
- config the hdns server used to, default use hdns.io.
There was a problem hiding this comment.
How does hdns.io work? They aren't signing records so there's no way to verify that the TLSA is correct.
There was a problem hiding this comment.
@rithvikvibhu hdns.io is a handshake name resolver that can get tlsa record of one name through the ns server you set on to the handshake blockchain.
There was a problem hiding this comment.
True, but to be able to trust the TLSA record is correct, the resolver should sign it (DNSSEC). Even if the nameserver is picked up from the blockchain, the address can be at any depth (abc.def.efg.handshakename) so it will need recursive resolving.
That's why it's not possible to get HTTP/DANE with https://hdns.io currently, because the TLSA record cannot be trusted.
There was a problem hiding this comment.
@rithvikvibhu the resolver doesnt sign TLSA, the zone owner would and they just serve the RRSIG from their nameserver. It's the resolvers job to verify all the signatures. As far as I can tell, hdns' recursive resolver does verify dnssec (ad bit is set):
--> dig @103.196.38.38 _443._tcp.proofofconcept tlsa +dnssec
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
_443._tcp.proofofconcept. 3600 IN TLSA 3 1 1 22E3C95A736E370FA38E7D94239F49C7A9EF961AF94E05AE8CC74FC3 CA2BA5CE
_443._tcp.proofofconcept. 86400 IN RRSIG TLSA 8 3 3600 20220225162619 20210224162619 58608 proofofconcept. gCIZIIm6KkUDDee4kqmuEjZ9hhTUPgoORUKwgTrzlIVV0p+4B83duHWV S/amZfpNwM0vWJ25If9UstG/q6QI1PrbJuSoonKl9eXaAihbZ1csfV4Q 7hC2JyrlarAsv7VjvnQwc31DYxywwOCfLuV5aeo1CFLrtsOGgnG6eJXp MXb79351FqBS2xVUvNyZfMLFcVq5xgAenH3JP5KwuOsBgNw+1mtLBg8N DQVQaIlPz/9/l9wrDqhuzhciOhFkHHZcq/cD/W1xsEgTJow3WdaIbAs1 FTy7CwowPeiYLD9RCnTYMv66cdCEvqKUgIHa2ib9k9d0D8zmoQNhIxHJ H9fSDQ==
However I do not think their DoH service does dnssec, I'm still trying to figure that out.
There was a problem hiding this comment.
Ahh, my bad, got confused there. You're right @pinheadmz and @v1xingyue.
Just tried it and looks like it only works for handshake domains:
Has RRSIG:
dig @1.1.1.1 _443._tcp.torproject.org TLSA +dnssecDoesn't have RRSIG:
dig @103.196.38.38 _443._tcp.torproject.org TLSA +dnssecThere was a problem hiding this comment.
What?! that is fucking bonkers
|
Will this work with traditional CA as well? Or does it expect to be HNS + DANE? |
|
Before this is merged we also need to finish the HIP2 spec to protect users: handshake-org/HIPs#35 |
|
@pinheadmz Yes. |
|
@pinheadmz Also the name address started with a '@' prefix. |
| const init = hsd => hdns.setServers(['103.196.38.38', '103.196.38.39', '103.196.38.40'] ); | ||
|
|
There was a problem hiding this comment.
These servers do not have public keys prefixed and so they are like using http instead of https - any data retrieved from them is unsigned and therefore not secure. Notice in the readme for hdns that the examples have public keys included with the IP addresses, this is for SIG0 verification.
letsdane also uses the public key : ip construction to ensure that the data is authentic.
We might want to check that the hard-coded servers in hdns are still working (or update them if they are not): https://github.com/handshake-org/hdns/blob/276351e08f95677461c6fa8cc78911101f97aa99/lib/resolvconf.js#L10-L14
There was a problem hiding this comment.
Is it better use doh query tlsa record. If so , https://query.hdns.io/dns-query maybe better. It's provided by hdns.io.
There was a problem hiding this comment.
Yes HTTPS would be more secure but ironically that relies on legacy DNS and CA. So I think that's probably fine for convenience users but for cypherpunks itd be nice to have the option to plug in a full pubkey@IP identity for a trusted HNS resolver, or even connect to Fingertip by allowing the user to set proxy information like Firefox. This feature could also check if the user has configured Bob's DNS servers to be active and might be able to make a recursive request to itself. @rithvikvibhu can may chime in on this -- by default the hsd recursive port is 5350...
My last suggestion would be to use a stub resolver from bns to recursively resolve the TLSA record, anchored by the NS/DS record pair pulled directly from the blockchain. This would alleviate the need for Bob's ns and rs servers to be active.
|
Cause I haven't do this work for a long time. Please close this now. I will consider this work again. Hope it does not take a long time. |
|
With #465 merged, think we can close this now. Thanks for working on this @v1xingyue! |
Add wallet transfer support for hip-0002 . As #324 said.