When I get confused around how the python code connects to asyncio's socket stuff, I visit aiorpcx/rawsocket.py and check the RSClient class. This is where kyuupichan's code makes network connections and connects with asyncio. Access to the transport can be seen in RSTransport.connection_made(transport) in that same file, where the transport is queried for its peername: transport.get_extra_info('peername'). -- I'd like to look at the documentation of this. I think I find that from some keyword where the connection is initiated, maybe in the server code outside of aiorpcx. To find that I search for calls to `connect_rs` which is how aiorpcx exports its RSClient class constructor to look like a function. Popping around a bit: it's loop.create_connection . I can websearch that with some catalysing term like 'asyncio'. And it worked; here's the python documentation on this: https://docs.python.org/3/library/asyncio-eventloop.html#opening-network-con...

To get access to connection information from a peer, I'll likely need some part of the peer that is associated with an actual live connection. Still recomprehending where or how that is held in the electrumx source I'm looking at (which could be kyuupichan's or spesmilo's).

I'm kinda confused, my mental habits are messing with each other. I have some wrong assumptions. The session object is not an asyncio session object. It's a kyuupichan session object. It contains an attribute called 'transport'. This is also not an asyncio transport object, but rather a kyuupichan transport object.

session.transport._asyncio_transport :) (Pdb) p session.transport._asyncio_transport.get_extra_info('peername') ('23.88.0.175', 50002) (Pdb) p session.transport._asyncio_transport.get_extra_info('peercert') {} blargh, is this not an ssl connection?

I'm guessing that a peer cert is just not what I am hoping it is, some other thing. (Pdb) p session.transport._asyncio_transport.get_extra_info('cipher') ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256) (Pdb) p session.transport._asyncio_transport.get_extra_info('sslcontext') <ssl.SSLContext object at 0xffffb794c640> (Pdb) p session.transport._asyncio_transport.get_extra_info('ssl_object') <ssl.SSLObject object at 0xffffb7930c70>

note: i thought i was looking at the ssl context, but that's actually the ssl object, not the ssl context. i think the context is process-wide, where as the object is connection-specific. real ctx appears to give access to e.g. ca cert chains.

getpeercert(binary_form=False) method of ssl.SSLObject instance Returns a formatted version of the data in the certificate provided by the other end of the SSL channel. Return None if no certificate was provided, {} if a certificate was provided, but not validated. Looking up the avenues available for validation sounds like a useful rabbit hole. People must have been doing certificate pinning for openssl connections for a long time.

(Pdb) p peer.host 'sv.satoshi.io'

it's been years and nobody's implemented this! right now i have a draft 'irc format' proposal that looks like: sv.satoshi.io t s-sha256.f43a3b0fe7be10206074a8cf565671a4960f61 in the the code, a 'features' dict is used. i recall the protocol might send 'features' around, although they might be flags rather than strings. anyway the nearness to a little normativeness gives me enough reason to glance through ssl norms and see if there's a standard condensed way to list fingerprints of a cert associated with their digests

i'm getting a little too tense to do this well. here's openssl's format: SHA256 Fingerprint=E6:5A:5D:37:22:FC:EF:EA:4B:22:92:45:BC:49:D2:29:3D:84:19:BC:C3:45:23:A1:22:A4:99:20:9D:03:E6:47 I could use an equal sign instead of a dot to make it look more normative

given the value of sharing these fingerprints, i'll take a pause, leave the code broken just for a bit to hopefully return, and try to enumerate more of them. this will mean roughly using some code to enumerate the hardcoded coin peers from spesmilo's coins.py

the script to enumerate cert fingerprints didn't output what i wanted, the output seemed short, etc. i'll try to attach it to this post to the wrong thread.

sv.satoshi.io s t xsha256=f43a3b0fe7be10206074a8cf565671a4960f616d2b56ce4b66a6e100383b2b8a i think i added code for this to my local repository

how pubkey pinning differs from that much

Try pinning google's, or any letsencrypt, end service full DER certs, it's a maintenance headache because they're constantly changing. Pinning google's intermediate certs (pubkey or full DER), or the LE end service pubkeys, can reduce maintenance, with same security.

isn't a certificate just wrapping for a pubkey?

A wrapping, over that and more meta fields. P2P nets might not have use for much more than what's in the TOFU paragraph. Bitcoin's and other cryptos total lack of both wire privacy and coin privacy, still through to this day, almost seems nefariously intentional. Refs... openssl x509 -text https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html https://www.netcraft.com/internet-data-mining/ssl-survey/ https://www.ssllabs.com/ssl-pulse/ https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support... https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-inter... https://en.wikipedia.org/wiki/Transport_Layer_Security https://tools.ietf.org/html/rfc8446 https://github.com/OWASP/www-community/blob/master/pages/controls/Certificat... https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Ch... https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a31198d/d... https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf53691992/d... Recommendations for Secure Use of Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7525 Pervasive Monitoring Is an Attack https://tools.ietf.org/html/rfc7258 Privacy Considerations for Internet Protocols https://tools.ietf.org/html/rfc6973 Certificate Transparency https://tools.ietf.org/html/rfc6962 Strong Security Requirements for Internet Engineering Task Force Standard Protocols https://tools.ietf.org/html/rfc3365 Guidelines for Writing RFC Text on Security Considerations https://tools.ietf.org/html/rfc3552 IETF Policy on Wiretapping https://tools.ietf.org/html/rfc2804 IAB and IESG Statement on Cryptographic Technology and the Internet https://tools.ietf.org/html/rfc1984 Privacy Requirements for IETF Protocols https://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-01 It is the consensus of the IETF that our protocols be designed to avoid privacy violations to the extent possible. Handling Pervasive Monitoring in the IETF (perpass) (WG) https://www.ietf.org/proceedings/88/perpass.html https://www.ietf.org/mailman/listinfo/perpass Opportunistic Security: Some Protection Most of the Time https://tools.ietf.org/html/rfc7435.html

I had thought cert pinning was a normal further step after use of CA certs.

No, they are independent, because the CA's cannot be trusted. CA's are 3rd parties in it to make money, seamless browsing as a coproduct, not to provide e2e or endpoint security or insurance. And many CA's in global cert stores are pointless and risk of state coercion or rogue. Pinning is between you and owner of the server, period, as it should be. Non-pinned CA model is still a big MITM risk. Full DER cert pinning is fine if people believe CA's and the CA scheme, but the underlying pinning of the pubkey is what is actually securing the connection and is all that is really needed. Server owners really should be publishing signed hashes of their server certs in public on different infrastructure blockchains keybase twitter linktree etc, but they don't, so you have to ask them for hashes, which if done properly is better than believing some random CA's in a MITM environment.

How long's google been rotating their certs?

Years, but they probably still do not publish cert history so backverification is broken..