Re: [PATCH] JWT payloads break b64dec convertor
> On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
>> Improvements and suggestions welcome; flames and horror -> /dev/null ;-)
>
> Would anyone be interested in adding two new converters for this,
> working exactly like base64/b64dec but with the URL-compatible
> base64 encoding instead ? We could call them :
>
> u64dec
> u64enc
>
> Note that it can be a nice and useful exercise for a first-time
contribution,
> don't be ashamed guys!
>
> Willy
Hi,
I have came across the same use-case as Jonathan so I gave it a try and
implemented the converters for base64url variant.
- Regarding the converters name, I have just prefixed "u" and used
ubase64/ub64dec. Let me know if the names are not appropriate or if you
rather prefer to add an argument to existing converters.
- RFC1421 mention in base64.c is deprecated so I replaced it with
RFC4648 to which base64/b64dec converters seem to still apply.
- not sure if samples list in sample.c should be formatted/aligned after
the converters added in this patch. They seemed to be already not
completely aligned. Anyway I have done the aligning on a separate patch
so you can squash it or drop it at your convenience.
Testing Example:
haproxy.cfg:
http-request return content-type text/plain lf-string
%[req.hdr(Authorization),word(2,.),ub64dec]
client:
TOKEN =
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiZm9vIiwia2V5IjoiY2hhZTZBaFhhaTZlIn0.5VsVj7mdxVvo1wP5c0dVHnr-S_khnIdFkThqvwukmdg
$ curl -H "Authorization: Bearer ${TOKEN}" 127.0.0.1:8080
{"user":"foo","key":"chae6AhXai6e"}
--
Moemen MHEDHBI
>From e599ada315d01513e21f11cdff176cff1639b25c Mon Sep 17 00:00:00 2001
From: Moemen MHEDHBI
Date: Thu, 1 Apr 2021 20:53:59 +0200
Subject: [PATCH 1/2] MINOR: sample: add ub64dec and ubase64 converters
ub64dec and ubase64 are the base64url equivalent of b64dec and base64
converters. base64url encoding is the "URL and Filename Safe Alphabet"
variant of base64 encoding. It is also used in in JWT (JSON Web Token)
standard.
---
doc/configuration.txt| 11
include/haproxy/base64.h | 2 ++
src/base64.c | 54 +++-
src/sample.c | 38
4 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 7048fb63e..10098adef 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -15494,6 +15494,17 @@ base64
transfer binary content in a way that can be reliably transferred (e.g.
an SSL ID can be copied in a header).
+ub64dec
+ This converter is the base64url variant of b64dec converter. base64url
+ encoding is the "URL and Filename Safe Alphabet" variant of base64 encoding.
+ It is also the encoding used in JWT (JSON Web Token) standard.
+
+ Example:
+ http-request set-var(txn.token_payload) req.hdr(Authorization),word(2,.),ub64dec
+
+ubase64
+ This converter is the base64url variant of base64 converter.
+
bool
Returns a boolean TRUE if the input value of type signed integer is
non-null, otherwise returns FALSE. Used in conjunction with and(), it can be
diff --git a/include/haproxy/base64.h b/include/haproxy/base64.h
index 1756bc058..aea4e7a73 100644
--- a/include/haproxy/base64.h
+++ b/include/haproxy/base64.h
@@ -18,6 +18,8 @@
int a2base64(char *in, int ilen, char *out, int olen);
int base64dec(const char *in, size_t ilen, char *out, size_t olen);
+int a2base64url(char *in, int ilen, char *out, int olen);
+int base64urldec(const char *in, size_t ilen, char *out, size_t olen);
const char *s30tob64(int in, char *out);
int b64tos30(const char *in);
diff --git a/src/base64.c b/src/base64.c
index 53e4d65b2..38902523f 100644
--- a/src/base64.c
+++ b/src/base64.c
@@ -1,5 +1,5 @@
/*
- * ASCII <-> Base64 conversion as described in RFC1421.
+ * ASCII <-> Base64 conversion as described in RFC4648.
*
* Copyright 2006-2010 Willy Tarreau
* Copyright 2009-2010 Krzysztof Piotr Oledzki
@@ -138,6 +138,58 @@ int base64dec(const char *in, size_t ilen, char *out, size_t olen) {
return convlen;
}
+/* url variant of a2base64 */
+int a2base64url(char *in, int ilen, char *out, int olen){
+ int convlen;
+ convlen = a2base64(in,ilen,out,olen);
+ while (out[convlen-1]=='='){
+ convlen--;
+ out[convlen]='\0';
+ }
+ for(int i=0;idata = 0;
+ bin_len = base64urldec(smp->data.u.str.area, smp->data.u.str.data,
+ trash->area, trash->size);
+ if (bin_len < 0)
+ return 0;
+
+ trash->data = bin_len;
+ smp->data.u.str = *trash;
+ smp->data.type = SMP_T_BIN;
+ smp->flags &= ~SMP_F_CONST;
+ return 1;
+}
+
static int sample_conv_bin2base64(const struct arg *arg_p, struct sample *smp, void *private)
{
struct buffer *trash = get_trash_chunk();
@@ -1585,6 +1603,24 @@ static int sample_conv_bin2base64(const struct arg *arg_p, struct sample *smp, v
return 1;
}
+static int sample_conv_bin2base64url(const struct arg *arg_p, struct sample *smp, void *private)
+{
+ struct buffer *trash =
'show errors' - logging & reasons
Hi, I'm wondering if there is any ongoing development or improvement plans around the 'show errors' functionality? This has come out of cases where we upgraded HAProxy 1.8 -> 2.2, and $work customers started reporting requests that previously worked fine now return 400 Invalid Request errors. Two things stand out: - way to reliably capture that output, not being limited to the last error - messaging about WHY a given position is an error - partial list of reasons I've seen so far included below Partial list of low-level invalid request reasons - path/queryparams has character that was supposed to be encoded - header key invalid character for given position - header line malformed (no colon!) - header value invalid relative to prior pieces of request** ** This one is bugging me: user requests with an absolute URI as the urlpath, but the hostname in that URI does not match the hostname in the Host header. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
BYOB (Bring Your Own Board)
BYOB (Bring Your Own Board!) "Join us to receive new major gifts funding for your important mission." ~ Stefanie Stark VISIT HERE or press PLAY BUTTON below for 60 Second Video Overview "Major Gifts Ramp-Up is the single greatest virtual conference event I've experienced since the start of the pandemic!" ~ Deanna Woodall, YWCA Quad-Cities https://jimmylarose.lt.acemlnc.com/Prod/link-tracker?redirectUrl=aHR0cHMlM0ElMkYlMkZub25wcm9maXRjb25mZXJlbmNlcy5vcmclMkZtYWpvci1naWZ0cy1yYW1wLXVwJTJG=26605550=jimmylarose%2Eactivehosted%2Ecom=vbeBh1HJZ6KtT6pdCg2Rk3b7ImIKGlCdLGgtNBedJm0%3D=b4e69d94bf077ab3e7944b1f14cd3206=73A191A39A400 Dear Colleagues in Service, Calamities and major downturns in the economy occur every decade. While COVID-19 is unique, what's not unique is how to make it through a crisis. In order for your charity to navigate these unprecedented times and be stronger in the future join us for Major Gifts Ramp-Up. As it turns out Major Gifts Fundraising is more important than ever and will be the single greatest revenue generator your organization can rely on during uncertain times. We've raised millions over the last ninety days for charities across the spectrum. "Major Gifts Ramp-Up Saved our Nonprofit from COVID-19. We've been privileged to turn down PPP & EIDL so other nonprofits could access the funds they need to make it through the pandemic." ~ Brent Bohanan, Habitat for Humanity Simply put, money is oxygen. Without it you can't breathe. Is your organization on life support? Are you receiving the air you need to survive the social and economic crisis we're now facing? If you're a nonprofit executive board member, development officer, pastor, volunteer or marketing director it's time for you to RE-IMAGINE PHILANTHROPY in ways that transform both you and your important mission. If you're ready to flourish before, during and after COVID-19 Major Gifts Ramp-Up is the answer. Learn how to use your existing staff and resources to grow your organization by simply changing the way you function each day. Go from business as usual to fully funded revenues streams that will not only raise money for your immediate needs, but will install a permanent culture of philanthropy within your nonprofit. Here's what needs to be in place. 1. At least six months operating cash reserves. 2. An unrestricted endowment comprised of at least $500,000. 3. Ongoing, deep relationships with at least 100 major donors. 4. An agile Board made up of only five to seven experts. 5. A robust Case for Support that describes a heroic mission of scale to impact your community. 6. A five year plan for growing impact and revenue. VISIT HERE or press "PLAY BUTTON" above Following the Great Recession of 2008, the founders of NANOE conducted a study of 485 nonprofits that received capacity building grants during the recession. Only 15% of these organization were able to leverage that funding to grow their impact and revenue. When we studied those 15% who were successful, we learned the following: 1. They built more capacity over a five year period than those nonprofits who indicated they stagnated or declined during the same time period. 2. They grew budget, programs & donors, despite the recession. 3. They grew their nonprofits regardless of the size/involvement of their board. 4. They externalized their mission for the purpose of fundraising. 5. They developed board members who evaluated the chief executive and promoted the goals and values of the CEO. What was the common factor in the success of these nonprofits? A strong CEO or Executive Director who planned for the future and viewed fundraising as a top priority. Strong leaders understand that philanthropy is essential for your nonprofit's success and that 80% of philanthropy in the U.S. is from individuals and families. Don't let anyone tell you now is not the time to fund raise. Don't let anyone tell you things have to stay the same. Don't let a few panicked Board members hijack your nonprofit's future. The future of your organization will be determined by your strong staff leadership (not by your Board or political leaders). Now is the time to act! Major Gifts Ramp-Up Live is not nonprofit management 101! Meet the fundraising veterans who've raised millions. Join us to learn how you can build the financial capacity you need to secure your future. This virtual event will challenge everything you believe about the raising of money, and will make five, six and seven figure major gifts available to your nonprofit in the shortest period of time possible. Over 17,000 nonprofit executives from across the U.S. have already attended. THEY LOVE THESE EVENTS (and so do their boards!) Why? Because this fast-paced and provocative training have been customized for the audience in attendance. Prepare to hear the truth in ways you've never experienced before. You'll learn from the masters who defied convention and challenged the false thinking that keeps charities broke. "I've
Re: 2.2.12 and rsa/ecdsa cert regression (crash on startup) ?
On Thu, Apr 01, 2021 at 02:26:07PM +0200, William Lallemand wrote:
> On Thu, Apr 01, 2021 at 10:19:31AM +, Jarno Huuskonen wrote:
> > Hello,
> >
> > I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind.
> > (cert1.pem.ecdsa
> > cert1.pem.ecdsa.ocsp
> > cert1.pem.ocsp
> > cert1.pem.rsa
> > cert1.pem.rsa.ocsp
> > )
> >
>
> Thanks for the report, I can reproduce the problem, I'm investigating.
>
Could you try the attached patch?
Thanks
--
William Lallemand
>From 3adeb8baf45c2f775848770b349cfa5e3fdd561b Mon Sep 17 00:00:00 2001
From: William Lallemand
Date: Thu, 1 Apr 2021 15:48:21 +0200
Subject: [PATCH] BUG/MEDIUM: ssl: ckch_inst->ctx not assigned with
multi-bundle certificates
When backporting patch 8218aed ("BUG/MINOR: ssl: Fix update of default
certificate") in 2.2, a regression was introduced. The 2.2
multi-certificate loading code does not have the same code path and this
part was not modified, introducing a segfault when trying to start
haproxy with a multi-certificate bundle.
This patch fixes the problem by setting the ckch_inst->ctx variable in
ckch_inst_new_load_multi_store().
No backport needed, 2.2 only.
---
src/ssl_sock.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 14311370f3..627de34761 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -3340,9 +3340,16 @@ int ckch_inst_new_load_multi_store(const char *path, struct ckch_store *ckchs,
/* Mark a default context if none exists, using the ctx that has the most shared keys */
- if (!bind_conf->default_ctx) {
- for (i = SSL_SOCK_POSSIBLE_KT_COMBOS - 1; i >= 0; i--) {
- if (key_combos[i].ctx) {
+ for (i = SSL_SOCK_POSSIBLE_KT_COMBOS - 1; i >= 0; i--) {
+ if (key_combos[i].ctx) {
+ if (!ckch_inst->ctx) {
+/* Always keep a reference to the newly constructed SSL_CTX in the
+ * instance. This way if the instance has no SNIs, the SSL_CTX will
+ * still be linked. */
+SSL_CTX_up_ref(key_combos[i].ctx);
+ckch_inst->ctx = key_combos[i].ctx;
+ }
+ if (!bind_conf->default_ctx) {
bind_conf->default_ctx = key_combos[i].ctx;
bind_conf->default_ssl_conf = ssl_conf;
ckch_inst->is_default = 1;
--
2.26.3
Re: 2.2.12 and rsa/ecdsa cert regression (crash on startup) ?
On Thu, Apr 01, 2021 at 10:19:31AM +, Jarno Huuskonen wrote: > Hello, > > I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind. > (cert1.pem.ecdsa > cert1.pem.ecdsa.ocsp > cert1.pem.ocsp > cert1.pem.rsa > cert1.pem.rsa.ocsp > ) > Thanks for the report, I can reproduce the problem, I'm investigating. -- William Lallemand
2.2.12 and rsa/ecdsa cert regression (crash on startup) ?
Hello,
I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind.
(cert1.pem.ecdsa
cert1.pem.ecdsa.ocsp
cert1.pem.ocsp
cert1.pem.rsa
cert1.pem.rsa.ocsp
)
haproxy crashes on startup:
(gdb) bt
#0 0x7710f159 in SSL_CTX_up_ref () from /lib64/libssl.so.1.1
#1 0x0042e1a3 in ssl_sock_load_cert_sni (ckch_inst=0x9adf30,
bind_conf=bind_conf@entry=0x9a6590) at src/ssl_sock.c:2866
#2 0x0043186f in ssl_sock_load_ckchs (path=,
ssl_conf=, sni_filter=,
fcount=, err=0x7fffdb68, ckch_inst=0x7fffba08,
bind_conf=0x9a6590, ckchs=0x9a6ad0) at src/ssl_sock.c:3587
#3 ssl_sock_load_ckchs (path=, ckchs=0x9a6ad0,
bind_conf=0x9a6590, ssl_conf=, sni_filter=,
fcount=, ckch_inst=0x7fffba08, err=0x7fffdb68) at
src/ssl_sock.c:3572
#4 0x00431b84 in ssl_sock_load_cert (path=path@entry=0x9703b8
"/etc/haproxy/ssl/cert1.pem",
bind_conf=bind_conf@entry=0x9a6590, err=err@entry=0x7fffdb68) at
src/ssl_sock.c:3740
#5 0x0043bfbe in bind_parse_crt (args=0x7fffdc10,
cur_arg=, px=, conf=0x9a6590,
err=0x7fffdb68)
at src/cfgparse-ssl.c:645
#6 0x0048e57b in cfg_parse_listen (file=0x99b060
"/etc/haproxy/haproxy.cfg", linenum=116, args=0x7fffdc10, kwm=)
at src/cfgparse-listen.c:605
#7 0x0047fcab in readcfgfile (file=0x99b060
"/etc/haproxy/haproxy.cfg") at src/cfgparse.c:2087
#8 0x0052dd7c in init (argc=, argc@entry=6,
argv=, argv@entry=0x7fffe2f8) at src/haproxy.c:2050
#9 0x0041e3ca in main (argc=6, argv=0x7fffe2f8) at
src/haproxy.c:3180
(This is on rhel8:
HA-Proxy version 2.2.12-a723e77 2021/03/31 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2
2025.
Known bugs: http://www.haproxy.org/bugs/bugs-2.2.12.html
Running on: Linux 4.18.0-240.15.1.el8_3.x86_64 #1 SMP Wed Feb 3 03:12:15 EST
2021 x86_64
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv -Wno-
unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-
missing-field-initializers -Wno-stringop-overflow -Wno-cast-function-type -
Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -
Wnull-dereference
OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
USE_ZLIB=1 USE_SYSTEMD=1
DEBUG =
Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT
+POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE -
STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H
+GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ
+CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -
OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=2).
Built with OpenSSL version : OpenSSL 1.1.1g FIPS 21 Apr 2020
Running on OpenSSL version : OpenSSL 1.1.1g FIPS 21 Apr 2020
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with PCRE2 version : 10.32 2018-09-10
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 8.3.1 20191121 (Red Hat 8.3.1-5)
Built with the Prometheus exporter as a service
)
Crash doesn't happen if I use just ecdsa or rsa cert file:
cert1.pem
cert1.pem.ocsp
(Crash also doesn't happen on 2.2.10, 2.2.11, 2.3.9 and 2.4dev(haproxy-ss-
20210401))
Git bisect points to this commit:
commit b87c8899d872843c12b3516ad51da84b22538d91
BUG/MINOR: ssl: Fix update of default certificate
Something like this config should be able to reproduce:
frontend FE_crash
bind ipv4@:443 name crashv4ssl ssl crt /etc/haproxy/ssl/cert1.pem
alpn h2,http/1.1
bind ipv6@:::443 name crashv6ssl ssl crt /etc/haproxy/ssl/cert1.pem
alpn h2,http/1.1
modehttp
default_backend BE_crash
backend BE_crash
server crash 192.168.1.105:8081 id 1 check
(And cert1.pem is multiple files:
cert1.pem.ecdsa
cert1.pem.ecdsa.ocsp
cert1.pem.ocsp
cert1.pem.rsa
cert1.pem.rsa.ocsp
)
-Jarno
--
Jarno Huuskonen
