Closed ferbs closed 1 year ago
hi @ferbs , what are you doing to fix the issue?
I had been trying it in Caddy using a "rediss:" site block protocol, which it seemed to accept. Turns out it wasn't actually applying their L4 proxy, it was treating it as an http/L7 endpoint. My impression is that their L4 proxy is experimental but under active development, so I'm waiting. If I run out of time waiting, I might try to apply the Caddy-managed acme certs to redis, or else move it to a subdomain and figure out some other proxy, maybe stunnel, their separate L4 app, or something else.
On 1 Aug 2023, at 1:43, farisam wrote:
hi @ferbs , what are you doing to fix the issue?
-- Reply to this email directly or view it on GitHub: https://github.com/redis/ioredis/issues/1696#issuecomment-1659603432 You are receiving this because you were mentioned.
Message ID: @.***>
I'm trying to connect IORedis v5.2.4 to a redis server behind a gateway (Caddy v2.5.1). All seems to work fine without SSL/TLS but IORedis can't connect when using either a "redis://" schema or with tls config options.
rediss:// schema attempt:
...results in:
....with strange TLS handshake problems reported by the gateway:
TLS-options attempt:
...results in:
...but with no TLS problems reported by the gateway:
A tcpdump confirms traffic is ciphertext
17:44:18.959090 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [S], seq 1717281641, win 65495, options [mss 65495,sackOK,TS val 1324065157 ecr 0,nop,wscale 7], length 0 E..<.9@.@.K.............f[.i.........0......... N........... 17:44:18.959101 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [S.], seq 2087445893, ack 1717281642, win 65483, options [mss 65495,sackOK,TS val 1324065157 ecr 1324065157,nop,wscale 7], length 0 E..<..@.@.<.............|k..f[.j.....0......... N...N....... 17:44:18.959108 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [.], ack 1, win 512, options [nop,nop,TS val 1324065157 ecr 1324065157], length 0 E..4.:@.@.K.............f[.j|k.......(..... N...N... 17:44:18.959311 lo In IP 127.0.0.1.55234 > 127.0.0.1.6321: Flags [P.], seq 1:364, ack 1, win 512, options [nop,nop,TS val 1324065157 ecr 1324065157], length 363 E....;@.@.J.............f[.j|k............. N...N.......f...b..C"F...HX(.LQ.Y&..v...X..O _.O? $ e>.j.i..%V...RP]..%...3\..y,.U'..v......./.+.0.,...'.g.(.k...................].a.W.S...........\.`.V.R.$.j.#.@. ...9.8. ...3.2.......Q.......P.=.<.5./.............. localhost......... ... ...........#.............0............. . .................................+........-.....3.&.$... ....\..VQ^ |.fH(...!.+e9.{.e...k 17:44:18.959316 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [.], ack 364, win 509, options [nop,nop,TS val 1324065157 ecr 1324065157], length 0 E..4Na@.@..`............|k..f[.......(..... N...N... 17:44:18.959762 lo In IP 127.0.0.1.6321 > 127.0.0.1.55234: Flags [P.], seq 1:1423, ack 364, win 512, options [nop,nop,TS val 1324065158 ecr 1324065157], length 1422 E...Nb@.@...............|k..f[............. N...N.......z...v..nf6.9.{.......I...S........q.m.. e>.j.i..%V...RP]..%...3\..y,.U'.......+.....3.$... 8.\.P.; @.qc..W.M....d....Uf...]............{..{.k..8..6.. cLNW..=.......bFxL.O?_.b{.....5@._4....a..$on....an....'O..:.9........S}....W...@........{.... .......9.2....>xp....P.#W_U;!BT......,<&}.5... ......(..[].o......uj....wr...^:5%.....x.cs.D.. .;..#....4........Z..y.TL.......x......IG....tZ.O..C........*z.n..i...-. Q.v..S|gq....`J.eA....X.|E..=.i...[dn.I..~...BY..<.....v.C.t..Y.h.[>... ..0.......l...$... ...9.."b^.Ss...-.$R<..f.^.0..@....N.).T..<.D!..mif.....98.|.Nf. T`.z.D....7.|.=l...J.{S.C.B...=.`rK..`.....cCB[ID.6.lI..........f...1.3...22...!.......:m..)..[.n.C.7E...0h..V.. .Zw^.A4..:........G#.Z...zI..E..........j:... ^.., ........2....F...-... .Ix.5...1....Y.ZS.....a.5......w.....0pN@..q....8...>.[qn.z.pE.....%l**[...:.+4!...3.~.'...0..aD{.s....Y...`+M..F..3M...q*..H....p..7.D..e..k.zr.l.Z....^zQ.}....OE ...S.... >.I confirmed regular https traffic is fine using a similar gateway config on localhost.
Any suggestions?