Print

[jimski]

Can anyone explain me how to use Redis to store SSLSessionCache for mod_ssl on Windows?

Current choices are:
none
nonenotnull
dbm:/path/to/datafile
shmcb:/path/to/datafile[(size)] (requires mod_socache_dbm)

Bu I don't see how they can be used with Redis.

[Gregg]

Who said it could? I know absolutely zilch about Redis other than the 5 minute scan of the docs I just took. It looks like socache_dc could be used on Unix but socache_dc is not built on Windows, obviously. Windoze doesn't have Unix sockets so it is understandable why.

This doesn't mean it's not possible, just seems unlikely.

I think Mario knows a thing or two about Redis so he may know. His new job has him away from home often so it may not be till this coming weekend before he can comment.

I see all you've gotten on this in AL's forum is the sound of crickets ... sorry I cannot be of any help.

[jimski]

Hi Gregg

I found this https://github.com/photom/mod_socache_redis

Can this be compiled for Apache on windows?


-------------- About Redis -------------
Redis is very fast in-memory database which can have also persistance to disk. It doesn't use SQL and it can be installed and configured on windows. I use it a lot on large-multi-server projects for php session caching. There are redis php extensions for windows.
To use it with php you have to edit php.ini and add this:
extension=php_redis.dll
...
;session.save_handler=files           
;session.save_path=c:\Temp
session.save_handler=redis
session.save_path=tcp://10.0.0.15:6379      (this is the IP address of redis database and port)
That's it.  Then all php sessions will be stored in redis database in memory.

However it would be also nice to be able to use it for SSLcache with Apache on windows.

[Gregg]

FINALLY, a module author that utilizes APR instead of gcc specific headers/functions when writing a module for Apache. I haven't even downloaded the source yet and I am already impressed. I'll give a whirl either tonight or sometime tomorrow

[Gregg]

Hi Jim,

Well, I'm backtracking on my 'impressed' but I did get them to compile with a little adjustment.

It used strings.h which looks to be BSD POSIX but our string.h is supposed to have the non-standard functions in it. We'll see.

I do not know why VC++ cannot handle this

Code: [Select]

    const int VEC_SIZE = 11;
    struct iovec vec[VEC_SIZE];but it can't.

There are a few of those of different sizes so I just had to hard code 'vec' to whatever size VEC_SIZE was set to the line above it. I've certainly run into this quite a few times.

It loaded for me and showed up in /server-info .. that's as far as I can go.
It's says it's an example module in mod_socache_redis.c so YMMV if it even works.

mod_socache_redis-vc14.zip

[jimski]

Thanks Gregg for compiling it.

I will install it on my server and see if it will connect to Redis.

I will post an update tomorrow.

[mario]

Code: [Select]

    const int VEC_SIZE = 11;
    struct iovec vec[VEC_SIZE];but it can't.

There are a few of those of different sizes so I just had to hard code 'vec' to whatever size VEC_SIZE was set to the line above it. I've certainly run into this quite a few times.

So it is now this?

Code: [Select]

struct iovec vec[11];


if yes I could open a bug on github.

[jimski]

I tested the new mod_sochache_redis on Windows 7 with Apache 2.4.20 connecting to a remote Redis store and it works great.

The mod_ssl performed 20 to 30% faster with mod_sochache_redis as opposed to not using any cache at all. The test sample was small so these numbers are not very accurate but the performance boost was visible.

Also, when mod_socache_redis fails to connect to Redis db (if Redis is down) then mod_ssl still works but just falls back to "no cache" mode.

I will put it into light production next week.

Thanks to Gregg we have a new module for windows.

[Gregg]

@Jim,
Cool!
I look forward to hearing how it does in light production versus testing.

@Mario,
Ummmm, I'll get back to you on that. I want to try a few things out when it comes to strings.h because of something that happened as I was trying to work around it that leaves me to believe it may not even be needed, at least on Windows. I wish I could find a copy of strings.h but when I google for it I did not see one to look at.

As for VEC_SIZE it is used later on in a function call. It being a constant, and not used but twice, why not drop it completely and save a couple bytes in each of the functions it's used in.

After 7pm and it's still 88F, you having a heat wave?

[Gregg]

oops, a little ahead of myself and since any notifications will have already been sent, sorry.

[Gregg]

@jimski

Mind testing this one? This one compiles on VC9, 11 & 14 and if it can handle your light production, it will be the one I will eventually put on the download page.
mod_socache_redis-v2-vc14.zip

@Mario, the answer to your question is yes. That takes care of that specific problem. It's interesting we can use things #defined, but not variables.

I've concluded that strings.h in apr_redis.c is a typo. Not a single function in this header is used.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/strings.h.html
string.h on the other hand is needed for strcmp().

There is a bit of C99 declaring going on too. I think we're stuck with C89 for a few more years. VC9/10/11 are C89

Overall tho it was not terribly hard to make it build on all our VC versions. I do not think I broke gcc either.

[jimski]

Gregg, the mod_socache_redis-v2-vc14.zip also works fine.

By looking into the code can you tell what happens if two redis servers are specified in the configuration directive:
SSLSessionCache         "redis:10.0.0.11:6379, 10.0.0.12:6379"

Specifically, will the same SSL session be cached to both Redis servers or just to the first one that is available?


-------------- Note About Security of mod_socache_redis,  mod_socache_memcache and other SSLSession caching methods.

Although I'm not aware of any specific attack conducted with the method described below, there is a potential weakness in OpenSSL related to session tickets. Currently OpenSSL doesn't allow limit for session tickets' lifetime. A new ticket key only gets generated when starting the web server and that key is continuously used until next restart.

This can lead to a potential exploit if an attacker figures out the key then that key can be used to decrypt any previous and future tickets until Apache is restarted. If you guys plan to use SSL session cache then you may want to consider restarting Apache once a while (preferable every day although my servers restart just once a week) using a task scheduler or cron.

Also, do not specify the SSLSessionTicketFile directive or comment it out. This will force Apache to auto generate a new ticket key on each restart.

This is not a huge weakness as decrypting or figuring out ticket keys is not an easy task, but it should be taken under consideration because some servers can run for months or years without a restart which may give an attacker enough time to figure out the ticket key.

[Gregg]

Kind of hard to tell (for me anyway)
But, if it allows configuration of more than one, shouldn't it send to all configured. If it just sent to the first one on the list that is live and not the others, if the first one went down, the session would be lost till such time as the first is brought back to life.

I would imagine it would send it to all for redundancies sake.

Being that this was a modified mod_socache_memcache and apr_memcache one would assume it would work exactly the same. I betcha someone on the users mailing would know for memcache. There are some really sharp folks on it including many of the developers.

[Gregg]

You added that while I was posting mine.

I do know about that but not for SSL session caching. It came up on the dev list back when forward secrecy was new. Every 24 hours was the recommended minimum.

My only complaint about that is the pollution in the error log. I swear we need some way to silence the :notice messages. If you restart the server everyday it becomes hard to find actual errors without grepping the file and you get 100MB error logs quickly.

Do I need to know the below every time my server restarts? NO! If it is not acting right sure, that's what debug, info and trace are for. Worse is you get two copies of it, one for the parent and one for the child process. It must really be a mess if you have many child processes.

[Sun Oct 11 00:20:59.078125 2015] [mpm_winnt:notice] [pid 4760:tid 704] AH00455: Apache/2.4.17 (Win32) OpenSSL/1.0.2d  configured -- resuming normal operations
[Sun Oct 11 00:20:59.078125 2015] [mpm_winnt:notice] [pid 4760:tid 704] AH00456: Server built: Oct  9 2015 16:02:53
[Sun Oct 11 00:20:59.078125 2015] [core:notice] [pid 4760:tid 704] AH00094: Command line: 'C:\\Apache24\\bin\\httpd.exe -d C:/Apache24'

To make matters worse, module developers have been jumping on the bandwagon and using it as well so there can be a whole lot more.

So every 24 hours has it's downside. Wherever you got that, he says he only does it once a week. I might try that myself and see how long it takes to get a 100MB error log.

[jimski]

....Wherever you got that, he says he only does it once a week. I might try that myself and see how long it takes to get a 100MB error log.

I didn't get that anywhere. This post above is in my own words and what I wrote describes what I actually do on my servers (restarting once a week) at 3:00 AM on Monday, when everybody sleeps.

I also stagger the restart so all my backend webservers never restart at the same time that way my load balancer can redirect the traffic to those servers that are up.

Oh, and the mod_socache_redis will add two extra lines to your log on start
[Fri Aug 26 15:39:28.244640 2016] [:notice] [pid 23352:tid 392] apr_redis_add_server host:10.0.0.11:6379
[Fri Aug 26 15:39:28.244640 2016] [:notice] [pid 23352:tid 392] make_server_live host:10.0.0.11:6379