HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dlundquist
sniproxy
C2017–2021
dlundquist / sniproxy

sniproxy

Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session.

3Distinct people
3Mentions
0Explicit recommenders
2.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year3 dated mentions

Observed mentions: 2017-03-30 04:07:15 UTC to 2021-01-08 08:28:58 UTC.

012017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

3 sources
https://github.com/dlundquist/sniproxy does not yet support ESNI. But might supporting ECH be completely infeasible? So for those unfamiliar, sniproxy is able to forward traffic to virtual hosts with their own encryption keys, by dispatching the connection based on the SNI of the handshake. After determining the correct vhost it initiates its own handshake with the destination and then hands the connection over to the original client, so the host running sniproxy does not need access to any keys or certificates.
In Encrypted Client Hello: The Future of ESNI in Firefox
You are reading things into my comments. Whether leaking the domainname in the Client Hello packet bothers a user or not is up to them. I simply brought it up as a consideration. I have a particular dislike for SNI because it requires modifying software that works just fine without SNI. I happen to like this software better than complex programs like "modern" browsers or command line programs with hundreds of thousands of lines of code and vast arrays of "features". Whether anyone else cares about such things, I have no idea. With HN, there may be some readers there with a similar aesthetic to mine. But probably very few if any. As a user, I do not need SNI. I am not very motivated to modify software to support it. Especially when it moves the hostname out of the encrypted stream. Secret reasons? FUD? Are you kidding? Information a
Read the rest
bout SNI is all over the web, in well-known places, from GitHub to StackExchange to Wikipedia. One does not have to chase up RFCs and dissect pcap files to verify what it does. https://github.com/dlundquist/sniproxy/ Here is an example of a proxy that uses the plain text hostnames to do redirection. https://security.stackexchange.com/questions/86723/ There are so many questions about SNI on stackexchange I do not know which one to choose. Here is a random example. https://en.wikipedia.org/wiki/Server_Name_Indication "The desired hostname is not encrypted."[2] I am the last person to tell other users what software to use. No one would want to use my selections. I work in VGA textmode. Everyday I see people telling other what software to use or not use, ad nauseum, in forum comments. I see little respect for users, especially from the large tech companies who assume all users are like lumps of clay to be molded however it suits them. That you think I am doing this I find amusing. Again, my "desktop" is a VGA textmode console. The number of users who would choose such a working environment in the face of tech company marketing is minute. Now, that is not to say I do not think they could easily adapt to textmode. I know they could because I saw many users do this in the 90's. I do not make assumptions about what users can handle. I am not trying to delibrately sell anyone on my software aesthetic. More accurately, what I was trying to do in my original comment, before getting suckered into arguing over inane comments (and I apologize for this), was to make a whimpering plea to the folks who are driving the SSL/TLS bandwagon. The IETF types. I think they deplore unconventional users like me so the idea of pleading with them is probably futile to begin with. Maybe other users would care, too? I have read that someone has proposed a draft solution to exposing the hostnames in plain text. That is a start. Perhaps they are begginning to acknowledge they can do better. The bizarre nature of your concern with my dislike for SNI actually suggests you are wielding some sort of FUD. Why do you care about what users know? You do not want users to question the merits of SNI? As far as I know, the sole purpose SNI is for virtual hosting. Maybe you work for a hosting company? Maybe you are a small website owner who does not have a dedicated IP address? And you want to run multiple https sites from the same IP? There are reasons to defend SNI but no one in these comments raised them. To conclude, judging by the comments from openasocket, it may be that ISPs will be mining DNS requests as the primary means of profiling users for marketing their data to third parties. If that is the case, there are solutions for users. Avoiding third party DNS, or even DNS altogether, is easy. Encrypting DNS packets is also easy. Avoiding SSL/TLS on the www is probably impossible. It has spread like the plague, with hordes of staunch defenders who will not tolerate any experimental ideas that could be used as alternatives. For them it is SSL/TLS or nothing. The biggest threat to privacy is probably ignorance and blind faith.
In The House just voted to wipe out the FCC’s landmark Internet privacy protections

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.