Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

block requests from a Lua script #224

Open
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

Habbie
Copy link
Contributor

@Habbie Habbie commented Feb 7, 2017

This PR adds the ability to reject requests from a Lua script. It has a lot of commits - I left them in on purpose so you can follow development a bit. If at some point you are ready to merge, I am happy to squash this work.

I wanted to add tests but I have the impression there are no real tests for TLS functionality at all right now so I had little to go on (please let me know if I missed something). I can add tests later if you want. For now I would love some feedback on the work in general.

Habbie and others added 18 commits February 7, 2017 09:34
…sr/include/lua5.1' LIBS='-llua5.1'

see sniproxy.lua for example. Note that there is no hostname normalisation, so adding a dot or uppercasing a letter would circumvent this simple example.
On empty SNI, -2 is stored in the hostname_len field. Since it's
an unsigned type (size_t), this leads to an _interesting_ behavior.
This was correctly handled in the existing parts of sniproxy, but
not in the new Lua code.
Otherwise we might get in trouble if some platform / version
decide to change the textual representation of IPv4-mapped addresses.
make sure addr is a valid nul-terminated string
avoid useless strlen call
@dlundquist
Copy link
Owner

dlundquist commented Feb 13, 2017

@Habbie Thanks for the patch. I haven't had much time to dedicate to sniproxy lately, so sorry for the late reply. If we are embedding LUA and making a call for each request, do we want to give it the the flexibility to do more than return a simple boolean to accept the request or not? I do see that an external firewall can not filter on source IP/requested hostname tuples, but it seems like if we are going to include and maintain such a feature it should be the best interface between LUA and sniproxy as possible. Perhaps the same LUA call could return more information on how to handle the request: which server to connect (optionally bypassing the table lookup)? I would like to hear are your thoughts on this?

The reason for the lack of TLS tests is that the HTTP protocol was actually introduced to aid testing since it is easier to debug plain text request. Can we test this LUA embedding with HTTP too?

@Habbie
Copy link
Contributor Author

Habbie commented Feb 13, 2017

  1. You got me - my initial plan in fact was to make the Lua -replace- a table but I couldn't get that to work and I did not have a lot of time available at that moment, so I went for the simpler option for now. But I agree, it would be great if the Lua hook could do more. I may take a shot at that but it will not be soon. Right now I just wanted to put the code out there to get feedback, so thank you for that :)
  2. I actually have not tested the Lua hook with HTTP, but you're right, if that works (and it really should) that would at least allow us to test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants