有用过ssl_session_fetch_by_lua/store_by_lua的哥们吗？给点指导。。

382482175 · 2016-08-10T22:54:18+00:00

Hello你可以自己在 Lua 代码里实现，负载均衡的方&#x...

有用过ssl_session_fetch_by_lua/store_by_lua的哥们吗？给点指导。。

382482175

做ssl session cross host resumption

现在用的是openresty-1.9.7.5 . openssl-1.0.2h 已经打入了patch。

配置文件如下：

server {

server_name localhost;

listen 443;

ssl on;

ssl_certificate '../ssl/nginx2.crt';

ssl_certificate_key '../ssl/nginx2.key';

ssl_session_fetch_by_lua_file '../lua_file/src/ssl_session/session_fetch.lua';

# access_by_lua_file '../lua_file/src/ssl_session/log.lua';

location / {

content_by_lua_file '../lua_file/src/ssl_session/test.lua';

# root html;

# index index.htm index.html;

}

session_fetch脚本如下：

local ssl_sess=require('ngx.sl.session')

local sess_id,err=ssl_sess.get_session_id()

if not sess_id then

ngx.log(ngx.ERR,"failed to get session id: ",err)

else

ngx.log(ngx.ERR,"session ID: ",sess_id)

end

ngx.log(ngx.ERR,"anything???")

可以正常运行https，但貌似这个脚本没有被执行？？是我使用的方式有问题吗？

：（

382482175

另外 ssl_session_store_by_lua指令可以正常执行，但fetch指令执行不了。。看文档这两个阶段都是在握手之前进行的，为啥fecth不执行呢？。。。。用的lua－module模块也是ssl-session-lua-module版本的。

在 2016年8月10日星期三 UTC-7上午7:54:18，wwaz wwaz写道：

做ssl session cross host resumption
现在用的是openresty-1.9.7.5 . openssl-1.0.2h 已经打入了patch。

配置文件如下：
server {
server_name localhost;
listen 443;
ssl on;
ssl_certificate '../ssl/nginx2.crt';
ssl_certificate_key '../ssl/nginx2.key';

ssl_session_fetch_by_lua_file '../lua_file/src/ssl_session/session_fetch.lua';
# access_by_lua_file '../lua_file/src/ssl_session/log.lua';

location / {
content_by_lua_file '../lua_file/src/ssl_session/test.lua';
# root html;
# index index.htm index.html;
}
}
}

session_fetch脚本如下：
local ssl_sess=require('ngx.sl.session')
local sess_id,err=ssl_sess.get_session_id()
if not sess_id then
ngx.log(ngx.ERR,"failed to get session id: ",err)

else
ngx.log(ngx.ERR,"session ID: ",sess_id)
end

ngx.log(ngx.ERR,"anything???")

可以正常运行https，但貌似这个脚本没有被执行？？是我使用的方式有问题吗？

：（

wanderpony

ssl_session_fetch/store_by_lua 这两个指令都是在 SSL Handshake 过程中使用的，客户端在 Client_Hello 阶段会把 session ID 发送过来，如果在 Nginx 这边能找到 Seesion ID，则直接复用之前 Full Handshake 计算出来的 master key 。

你存(store)到哪里（memcached/redis)就应该从哪里取(fetch)，如果你贴的 fetch 的代码就是你用的话，这几行就问题很多…… 😂

另外通过 SSL Session ID 共享 TLS Session Cache 的方式在客户端比较老( 不支持 Session Ticket )收益才比较大，结合自己情况，合理使用！

382482175

嗯，谢谢指教

我开始只是想验证下fetch阶段到底有没有执行，没有去写具体逻辑：）

不过现在突然就执行了（原先不执行不知道啥问题。。。）

另外你说的如果支持session ticket的话，那么添加这个逻辑的话会对性能有影响吗？

因为我在测试的时候，如果开启ticket，那么不会执行这两个阶段（目前本机的chrome测试是这样）。

在nginx.conf大会上，cloudflare也分享过ticket key轮转的方式，但具体代码并没有开源。。

在 2016年8月11日星期四 UTC-7上午10:32:00，Jianqiang Wang写道：

ssl_session_fetch/store_by_lua 这两个指令都是在 SSL Handshake 过程中使用的，客户端在 Client_Hello 阶段会把 session ID 发送过来，如果在 Nginx 这边能找到 Seesion ID，则直接复用之前 Full Handshake 计算出来的 master key 。
你存(store)到哪里（memcached/redis)就应该从哪里取(fetch)，如果你贴的 fetch 的代码就是你用的话，这几行就问题很多…… 😂
另外通过 SSL Session ID 共享 TLS Session Cache 的方式在客户端比较老( 不支持 Session Ticket )收益才比较大，结合自己情况，合理使用！

wanderpony

当 Client_Hello 中同时包含 TLS Session ID 和 TLS Session Ticket 时，OpenSSL 是会优先使用 TLS Session Ticket 方式复用 TLS Session 的，所以你测试开启 ssl_session_ticket 时，是不会执行的。通过 TLS Session Ticket 实现跨机器间的 TLS Session 共享是比较容易的，所有前端共享一个 ticket key 即可，定期换 ticket key 的实现有很多，比如 Twitter 的 SSH + tmpfs 方案，每隔 12 小时换一次 ticket key .....

On Friday, August 12, 2016 at 9:55:00 AM UTC+8, wwaz wwaz wrote:

嗯，谢谢指教
我开始只是想验证下fetch阶段到底有没有执行，没有去写具体逻辑：）
不过现在突然就执行了（原先不执行不知道啥问题。。。）

另外你说的如果支持session ticket的话，那么添加这个逻辑的话会对性能有影响吗？
因为我在测试的时候，如果开启ticket，那么不会执行这两个阶段（目前本机的chrome测试是这样）。
在nginx.conf大会上，cloudflare也分享过ticket key轮转的方式，但具体代码并没有开源。。

在 2016年8月11日星期四 UTC-7上午10:32:00，Jianqiang Wang写道：
ssl_session_fetch/store_by_lua 这两个指令都是在 SSL Handshake 过程中使用的，客户端在 Client_Hello 阶段会把 session ID 发送过来，如果在 Nginx 这边能找到 Seesion ID，则直接复用之前 Full Handshake 计算出来的 master key 。
你存(store)到哪里（memcached/redis)就应该从哪里取(fetch)，如果你贴的 fetch 的代码就是你用的话，这几行就问题很多…… 😂
另外通过 SSL Session ID 共享 TLS Session Cache 的方式在客户端比较老( 不支持 Session Ticket )收益才比较大，结合自己情况，合理使用！

agentzh

Hello!

2016-08-12 0:33 GMT-07:00 Jianqiang Wang:
>
> 通过 TLS Session Ticket 实现跨机器间的 TLS Session 共享是比较容易的，所有前端共享一个  ticket key 即可，定期换 ticket key 的实现有很多，比如 Twitter 的 SSH + tmpfs  方案，每隔 12 小时换一次 ticket key .....
>

我们很快也会开源基于 OpenResty 的自动同步 TLS session ticket key 的方案，这比 ssh + tmpfs
的做法优雅和灵活多了……

Regards,
-agentzh

382482175

👍👍👍

在 2016年8月17日星期三 UTC-7下午2:20:57，agentzh写道：

Hello!

2016-08-12 0:33 GMT-07:00 Jianqiang Wang:
>
> 通过 TLS Session Ticket 实现跨机器间的 TLS Session 共享是比较容易的，所有前端共享一个 ticket key 即可，定期换 ticket key 的实现有很多，比如 Twitter 的 SSH + tmpfs 方案，每隔 12 小时换一次 ticket key .....
>

我们很快也会开源基于 OpenResty 的自动同步 TLS session ticket key 的方案，这比 ssh + tmpfs
的做法优雅和灵活多了……

Regards,
-agentzh