You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know dict predates the total ascendant dominance of the web.
/etc/services:194:dict 2628/tcp
What would it take to make a TLS version of the protocol widely available by current server maintainers?
Interest in Transport Security for dict requests
Agreement on (if and) how to adopt current WebPKI practices.
Agreement on a distinct port to use, wanting eventual registration with IANA. (It's remarkable how many fewer services linux ships with than IANA has registered).
more elegant that sniffing connection packets, on the same port
Updates to server and client, to do connection setup.
Quality of life goal: Keeping open connections, or caching setup information, to avoid paying full TLS setup overhead on every request.
--
This question does seem a little silly. It seems like a large lift for a protocol mainly maintaining support. Have people written proxies, over other transport protocols or data formats, to allow use of the same clients and servers over a different medium. stunnel might be my minimum viable TLS proxy, but I'm interested beyond services hosted by me.
The text was updated successfully, but these errors were encountered:
I know dict predates the total ascendant dominance of the web.
What would it take to make a TLS version of the protocol widely available by current server maintainers?
--
This question does seem a little silly. It seems like a large lift for a protocol mainly maintaining support. Have people written proxies, over other transport protocols or data formats, to allow use of the same clients and servers over a different medium.
stunnel
might be my minimum viable TLS proxy, but I'm interested beyond services hosted by me.The text was updated successfully, but these errors were encountered: