Send cache updates to remote peers on UDP (redo clean pullreq) #50

Closed
wants to merge 3 commits into
from

Projects

None yet

2 participants

@EmericBr

On new session create, sessionid+ASN1 encoded session+creation timestamp+HMAC SHA1 signature of the message is sent to configured peers.

It supports mulitcast ipv4 and v6

Bench results seems good :)

emeric added some commits Oct 29, 2011
emeric Shared cache: add callback and function to receive/send cache updates
from/to a remote host
Note: Send call back provide encoded session into an aligned buffer
      large enougth to add a footer and send it directly to a peer
      using a sendto
99ecf5a
emeric Send and receive cache updates to/from remotes hosts on udp. 2a22d3e
emeric Add multicast support for cache updates exchange f91cdf3
@EmericBr

Appears clean now

Ex unicast sharing cache using 3 peers:
peers1:
./stud -C 10000 -U 192.168.0.10,8888 -P 192.168.0.11 -P 192.168.0.12 -f 192.168.0.10,443 -b 192.168.0.20,80 mycert.pem
peers2:
./stud -C 10000 -U 192.168.0.11,8888 -P 192.168.0.10 -P 192.168.0.12 -f 192.168.0.11,443 -b 192.168.0.20,80 mycert.pem
peers3:
./stud -C 10000 -U 192.168.0.12,8888 -P 192.168.0.11 -P 192.168.0.10 -f 192.168.0.12,443 -b 192.168.0.20,80 mycert.pem

Same example using multicast:
peers1:
./stud -C 10000 -U 224.2.2.2,8888 -P 224.2.2.2 -M eth0 -f 192.168.0.10,443 -b 192.168.0.20,80 mycert.pem
peers2:
./stud -C 10000 -U 224.2.2.2,8888 -P 224.2.2.2 -M eth0 -f 192.168.0.11,443 -b 192.168.0.20,80 mycert.pem
peers3:
./stud -C 10000 -U 224.2.2.2,8888 -P 224.2.2.2 -M eth0 -f 192.168.0.12,443 -b 192.168.0.20,80 mycert.pem

IPv6 unicast/multicast is also supported

@vincentbernat
Contributor

You should disable tickets when a remote cache is used. Something like this:

SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET);

Also, see my pull request 30: #30. I will update it when your patch is merged.

@EmericBr
EmericBr commented Nov 7, 2011

If client support tls TICKETs ext, there is no session resumption issue on single host, but using multiple host. i am wrong?.

Why disable SSL_OP_NO_TICKET? your pull request seems to fix the issue, and complete shared cache for client who supports tickets.

Note: On my commit 2a22d3e, you'll see i modified Private key loading part to avoid multiple pass phrase prompt request. I currently use an ASN1 of rsa private key as share secret to sign update packets. Firstly i used a shared secret on command line as you do but i don't like a clear secret on command line cause it appears on ps.

@vincentbernat
Contributor

Yes, when a client supports TLS tickets, the problem only appears with multiple hosts. I was only suggesting to disable tickets to ensure that your pull request can work without any other pull request. I will rewrite my pull request on top of yours and use the RSA private key to build the shared secret as you did.

@EmericBr
EmericBr commented Nov 7, 2011

Great! i will add the OP_NO_TICKET waiting your commit, don't forget to disable it :).

@EmericBr
EmericBr commented Nov 7, 2011

I add commit 8a997c4, i am not familiar with github pull request. Is it possible to add a commit to the current pull request?.

@vincentbernat
Contributor

Redo the pull request, this will update this one.

@vincentbernat
Contributor

I get a segfault when testing your patch. On the node receiving a session:


#0  shctx_sess_add (
    encsess=0x7fff6958b280 "\345\241Yל\003\211\212\307\333^\003\035\220\067", len=147, 
    cdate=1320673131) at shctx.c:320
        shsess = 0x0
#1  0x00000000004041bf in handle_shcupd (loop=<optimized out>, w=0x60a940, 
    revents=<optimized out>) at stud.c:293
        msg = "\345\241Yל\003\211\212\307\333^\003\035\220\067\000\223wpk\340\370}\346\221VBk\213\245\344\321\060q\002\001\001\002\002\003\001\004\002\000\071\004 \345\241Yל\003\211\212\307\333^\003\035\220\067\000\223wpk\340\370}\346\221VBk\213\245\344\321\004\060\337\324J\024\026˥U\\\277\237\322@\362\315\341(Y\274dԏ\352ra\031\207\205<c\037\375\221pb\222\376S\325/\324\003\222>>\344\377]\241\006\002\004N\267\337j\242\004\002\002\034 \244\002\004\000N\267\337j\207\356\245y\254\360{\353\343\036n9\270\263_C\341\375\275\365\000\000\000\000\000\270\264Xi\377\177\000\000\000 \025*\321\177\000\000\064\263\025\211\000\000\000\000R\311\365)\321\177", '\000' <repeats 18 times>, "\001", '\000' <repeats 15 times>, "\001\000\000\000\321\177\000\000\000 \025*\321\177\000\000\064d\005\374\000\000\000\000c\305\365)\321\177\000\000\001\000\000\000\001", '\000' <repeats 19 times>, "X#\025*\321\177\000\000@\264Xi\377\177\000\000X\264Xi\377\177\000\000\340"...
        hash = "\207\356\245y\254\360{\353\343\036n9\270\263_C\341\375\275\365\321\177\000\000\275)s)\321\177\000\000\240\234\223)\321\177\000\000\071\207[i\377\177\000\000p\265Xi\377\177\000\000\000\000\000\000\000\000\000"
        r = 147
        hash_len = 20
        encdate = <optimized out>
        now = 1320673131

The comment in the source code says shsess cannot be NULL. But it seems that I get NULL. Any idea?

@vincentbernat
Contributor

Some more info. On one node:

./stud -C 10000 -U 0.0.0.0,8888 -P 10.234.95.74,8888 -f 127.0.0.1,8443  -b www.luffy.cx,80 ~/tmp/c.pem

On the other node:

./stud -C 10000 -U 0.0.0.0,8888 -P 10.234.95.151,8888 -f 0.0.0.0,8443  -b www.luffy.cx,80 ~/tmp/c.pem

And to test (on the first node):

openssl s_client -tls1 -connect 127.0.0.1:8443 -no_ticket
@EmericBr
EmericBr commented Nov 7, 2011

47976cb fix, a regression after my tests, reviewing code to introduce macros.

@vincentbernat
Contributor

Works for me. I have updated my patch for sharing tickets. Can you have a look since I have modified some of your code to use SHA384. #30

@EmericBr
EmericBr commented Nov 7, 2011

ok, you are right to keep SHA1 for inter-node updates exchange (less than 1% cost during my tests).

I don't know how to add my last 2 commits to current pull request.

You say, redo the pool request, you mean keep the same name?.

@vincentbernat
Contributor

I am using feature branches so I am not sure if this works the same for
master. What I do to update a pull request is to go to my branch, click
on "Pull request", then Github detects there is already a pull request
for this branch and propose to update it.

Maybe this does not work this way with master.

@EmericBr
EmericBr commented Nov 8, 2011

i will use a branch the next time.

@EmericBr
EmericBr commented Nov 8, 2011

I've set my master up to date and create a new branch UpdateSHP, i resolved some conflicts. (I also merge bug fix 47976cb into 1de1173).

Vincent could you rebase on it?.

@EmericBr
EmericBr commented Nov 9, 2011

I'am waiting for jam feedback before redo a clean pull request and close this one.

@EmericBr EmericBr closed this Nov 29, 2011
@EmericBr

Recreate clean pull request in #60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment