💾 Archived View for bbs.geminispace.org › u › alexlehm › 5575 captured on 2023-12-28 at 17:24:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Re: "SNI for misfin: I am getting a "you didn't provide SNI"..."
Yes, it is definitely possible to do that, the message contains the user url in the beginning similar to a To-field in an email
Sep 26 · 3 months ago
😎 flipperzero · Sep 26 at 11:57:
Thank you for clarification. Sorry btw for unintended diversion, in order to address the post in question, to better understand I'd like to ask if you mean that the server you're trying to contact is using a different ssl lib from your server? Or, that the server you have running is using a different lib from the client you're using? Connecting that to my previous inquiry, could that possibly interfere between users of the same network using the server and client installed across workspace?
😎 flipperzero · Sep 26 at 12:57:
Update: @alexlehm IDK if you'd be able to help or pinpoint why this might be, but when I run receive-as I get this back
Receiving for Flip0 (flipperzero@hashnix.club)
OSError [Errno 99] Cannot assign requested address
Did I miss something?
@flipperzero You're getting this error because you're passing a certificate that has a x509 DNS subject alternative name that you can't "listen on". It needs to be a hostname that will resolve to an IP that's assigned to one of your network interfaces. I created the certificate with "localhost" like this, maybe it's also possible to pass an IP i don't know:
python -m transponder.debug make-cert flipperzero "Flipper" localhost mycert.pem
In transponder/misfin.py, in receive_forever(), add this line to output which hostname will listen on:
print((server.hostname, default_port))
😎 flipperzero · Sep 26 at 14:27:
@gemalaya thank you so much that did the trick! I also wondered if it had to do with, as stated in a previous post regarding being unable to assign "receive-as" by lem, the issue with compatibility between source and latest version of python. I was running into the same results related to OpenSSL, but your explanation clears everything up. thank you again :D
@flipperzero You're welcome. For misfin you need python >= 3.9. I hope to contribute to this project cause it's a really nice idea, i've just cleaned up the repo to be PEP8-compliant .. I'll add support for misfin in gemalaya, at least recognize misfin URLs and be able to send a message.
😎 flipperzero · Sep 26 at 15:05:
@alexlehm just in case anything has gone through, apologies for any multiple or redunant tests, sincerely :x
@filipperzero I think that means that the receiving address is not available as a local interface, the dns resolves to something else than your local machine
@flipperzero i don't think I got any msgs from you
I currently only log the messages to the java log, so if you want to send me test messages, no problem. a typical message looks like this: https://p.lehmann.cx/eE_4.txt
— https://p.lehmann.cx/eE_4.txt
📷 billsmugs · Sep 26 at 16:52:
My server is the one rejecting incoming messages due to lack of SNI. My misfin server code is essentially just my gemini server code with a few branches, so I didn't explicitly add this behaviour and only now realised that it's not actually part of the Misfin spec, sorry!
I feel like it would be worth adding to the spec though, like it is in the Gemini spec. Without SNI a server that hosts multiple domains doesn't know which certificate to present to an incoming connection.
I guess SNI can be used but should be optional, i.e. if there is no SNI it should present a default cert and then use that domain
📷 billsmugs · Sep 26 at 18:05:
For now I've put in a hacky fix to default to misfin.billsmugs.com for incoming connections on port 1958 that don't have SNI.
I do think the spec should explictly require SNI in future though, not make it optional.
🚀 clseibold · Sep 26 at 18:31:
@gemalaya The hostname provided in the cert is supposed to be what the server is listening on? So, if you use localhost, will people still be able to send mail to your server over the internet? I was under the impressin that your hostname had to match the domain that you intended others to use when typing your email, so for auragem, it would be auragem.letz.dev. However, does this domain need to resolve to your public IP on the computer you're on? Because I setup the local hosts file to resolve it to localhost, iirc, because loopback wasn't working for me.
@clseibold When you use "make-cert", the 3rd argument is the "hostname", and it's written in the certificate as the "X509v3 Subject Alternative Name" in the certificate, here's what it shows for a "localhost" cert:
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:localhost
When you run a server with "receive-as", misfin opens the certificate and reads that value (the "DNS"), the code is in misfin/identity.py (LocalIdentity, in the __init__):
I plan to rewrite this part because when you run a server for an infinite number of identities (recipients), you'd most definitely want to have more control over which IP you listen on.
🚀 clseibold · Sep 26 at 19:37:
@gemalaya Right, I'm aware that that's what it does. I've explained in the other thread why the bind address *has to* be different from the SubjAltName, because my system cannot and will never work with this assumption. There's no way around it. I was required to change the bind address because of this assumption. I cannot use my public ip address on my own network because I don't have loopback (I believe that's what it's called when you use your own public ip from within your own network).
@clseibold So yeah, right now, the hostname value that you pass when you create the certificate is the hostname that misfin will bind the socket to.
But note that you can also pass an IP address, i just did that and it works
misfin make-cert ip "IP" 192.168.1.28 28.pem misfin receive-as 28.pem Receiving for: IP (ip@192.168.1.28) Listening on: 192.168.1.28
🚀 clseibold · Sep 26 at 19:42:
@gemalaya Yes, it works, but now your certificate is incorrect. Your certificate has to be your domain name. Also, the bind address is what you want to listen on. I'm actually unsure if it needs to be the public IP, or the private IP of the computer (I think the private IP of the computer will work, actually).
Regardless, the cert has to be the domain name or every other server you send mail to will end up failing the verification.
@clseibold You're right. I'm working on a service command that will let you serve multiple identities and store messages, it's not too much work.
SNI for misfin: I am getting a "you didn't provide SNI" error in one misfin server when I try to access it via the Python client, apparently that uses a different ssl library. I wonder if that is intended, to work it has to be active in both the client and the server