Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

[Илья Шипицин]

сб, 15 июл. 2023 г. в 10:44, Willy Tarreau :

> Hi Alex, Andrew,
>
> On Thu, Jul 13, 2023 at 11:54:44AM +0200, Aleksandar Lazic wrote:
> > On 2023-07-13 (Do.) 08:22, Hopkins, Andrew wrote:
> > > * Do you plan to add quic (Server part) faster then OpenSSL?
> > >
> > > I have not looked into quic benchmarks but it uses the same
> > > cryptographic primitives as TLS so I imagine we'd be faster for a lot
> of
> > > the algorithms. It might not be useful for HAProxy which is all C, but
> > > AWS also launched s2n-quic [1] which does have extensive testing for
> > > correctness and performance. s2n-quic evenuses AWS-LC's libcrypto for
> > > all of the cryptographic operations [2] though our rust bindings
> > > aws-lc-rs [3].
> >
> > Hm, this implies a dependency for rust which increases the complexity to
> > build HAProxy. From my point of view isn't this very helpfull to bring
> the
> > library into haproxy.
>
> I think there was a misunderstanding between you two above. I understand
> Alex' question as "will you merge quic support soon", but my understanding
> last time I had the opportunity to discuss about AWS-LC was that it *is*
> already there. Alex, what Andrew mentioned above is that their own QUIC
> implementation, s2n-quic, uses their rust bindings, but we don't need
> s2n-quic (since we have our own stack) and this will not add any
> dependency.
>

I tried to build with USE_QUIC=1:

[ilia@fedora haproxy]$ sh go.sh
  CC  src/quic_conn.o
  CC  src/h3.o
  CC  src/xprt_quic.o
  CC  src/quic_frame.o
  CC  src/quic_tls.o
In file included from src/quic_conn.c:60:
include/haproxy/quic_tls.h: In function ‘tls_aead’:
include/haproxy/quic_tls.h:124:14: error: ‘TLS1_3_CK_AES_128_GCM_SHA256’
undeclared (first use in this function); did you mean
‘TLS1_CK_AES_128_GCM_SHA256’?
  124 | case TLS1_3_CK_AES_128_GCM_SHA256:
  |  ^~~~
  |  TLS1_CK_AES_128_GCM_SHA256
compilation terminated due to -Wfatal-errors.
make: *** [Makefile:998: src/quic_conn.o] Error 1
make: *** Waiting for unfinished jobs
[ilia@fedora haproxy]$


>
> > > * Will be there some packages for debian/ubuntu/RHEL/... so that the
> > > users of HAProxy can "just install and run" HAProxy with that SSL Lib?
> > >
> > > In the near future no. Currently AWS-LC does not support enough
> packages
> > > to fully replace libcrypto for the entire operating system, and
> > > balancing different programs using different library paths and
> libcrypto
> > > implementations is tricky. Eventually distributing static archives and
> > > shared libraries once we have more support makes sense. There is more
> > > context/history in this issue [4].
> >
> > Uh that's a show stopper, at least from my point of view. This implies
> the
> > same work as HAProxy team have for wolfssl, BoringSSL and quictls and
> that's
> > a lot of work.
>
> I think that what would be important would be to find a package maintainer
> willing to maintain this into a distro for the whole maintenance life cycle
> of that distro. It also helps a lot in designing stable and durable APIs
> that boost adoption, because the early maintenance trouble are quickly
> learned during backports and everyone is more careful over time.
>
> One thing that should really be avoided would be to name the library as
> the regular openssl one, because while it helps with *early* adoption,
> it complicates everything over time and for all packages. For example,
> quictls adopted the .81 suffix (81 for "Q") and as such there's no
> conflict on the shared lib. For building, it's as simple as passing the
> SSL_INC/SSL_LIB during the build (and basically all software supporting
> openssl support this), so there's no trouble either, and all libs can
> coexist on the same distro. But yeah, it's really important to find
> someone willing to maintain such a package long enough for a distro,
> that fills a hole that the whole world is waiting to be plugged (since
> we know it will not come from openssl anyway).
>
> The partial support from various software is not a problem as long as
> openssl and aws-lc can coexist on the system. Some will just be built
> with one and others with the other. This has always existed and I would
> be surprised if there's no software linked against GNUtls on distros
> that ship it for example. So if aws-lc enters say, debian and ubuntu
> LTS, and common software like curl, apache, nginx, ngtcp2, haproxy can
> build with it, we'll basically have what users are waiting for to fully
> enable QUIC, and with a lib that cares about performance. For now there
> is only wolfSSL in that place, and while it works pretty well, it
> requires more porting effort from applications and a sensible set of
> build settings still needs to be defined for distros. In any case, the
> more options for package maintainers, the better.
>
> Regards,
> Willy
>
>

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

[Hopkins, Andrew]

I have good news and bad news. The good news is I figured out why some of the 
HAProxy tests in AWS-LC’s CI were getting a different result than the HAProxy 
tests in your CI, I’ve fixed that in this PR [1] by installing more test 
dependencies (socat and lua). The bad news is I need to skip ssl_dh.vtc in 
HAProxy’s CI [2] for now. AWS-LC does not support any FFDH ciphersuites in our 
libssl, but we do support the operations in our libcrypto. The cipher suites we 
do support are:
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

[1] https://github.com/aws/aws-lc/pull/1097
[2] 
https://github.com/andrewhop/haproxy/pull/1/files#diff-0b21de6f7e1d44cc39f76a8d90c65fc0edbe75fd5327a20cfc9f45c79925e66b

From: Илья Шипицин 
Date: Saturday, July 15, 2023 at 1:30 PM
To: "Hopkins, Andrew" 
Cc: "haproxy@formilux.org" 
Subject: RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new cryptographic library 
AWS-LC


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Andrew,

I could not find how to enable "DHE-RSA-AES256-GCM-SHA384" on aws-lc (required 
by haproxy vtest)

*** h3 debug|[ALERT] (7370) : config : Proxy 'ssl-dhfile-lst': unable to set 
SSL cipher list to 'DHE-RSA-AES256-GCM-SHA384' for bind 
'/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/ssl_dhfile.sock' 
at [/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/h3/cfg:26].
*** h3 debug|Proxy 'ssl-dhfile-lst': unable to set SSL cipher list to 
'DHE-RSA-AES256-GCM-SHA384' for bind 
'/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/ssl_dhfile.sock' 
at [/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/h3/cfg:26].
*** h3 debug|[ALERT] (7370) : config : Fatal errors found in configuration.

ср, 12 июл. 2023 г. в 02:29, Hopkins, Andrew 
mailto:and...@amazon.com>>:
Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC) project [1]. 
Our goal is to improve the cryptography we use internally at AWS and help our 
customers externally. In the spirit of helping people use good crypto we know 
it’s important to make it easy to use AWS-LC everywhere they use cryptography. 
This is why we are interested in integrating AWS-LC into HAProxy.

AWS-LC is a fork of BoringSSL which you already partially support. We recently 
merged in several PRs (Full OCSP support [2] and custom extension support [3]) 
to fully support HAProxy the same as OpenSSL. To ensure we continue to support 
HAProxy long term we added HAProxy built with AWS-LC to our CI [4].

In our early testing we see modest improvements in overall throughput when 
compared to OpenSSL 3.1 on x86 and arm CPUs. Following a similar setup as this 
blog [5] I observe a small (~2.5%) increase in requests per second for 5 kb 
requests on a C6i (x86) and C6g (arm) instance using TLS 1.3 and AES 256 GCM. 
For both tests I used `taskset -c 2-47 ./h1load -e -ll -P -t 46 -s 30 -d 120 -c 
500 https://[c6i or c6g ip]:[aws-lc or openssl port]/?s=5k`.

This small difference in this symmetric crypto workload comes down to AWS-LC 
and OpenSSL having similar AES implementations. We observe larger performance 
improvements with our micro-benchmarks for algorithms related to the TLS 
handshake such as 15% reduction for ECDH with P-256, and 40% reduction for 
P-521 on a C6i. This comes from our s2n-bignum library[6], a formally verified 
bignum library with a focus on performance and correctness.

When built with AWS-LC all current regression tests pass. I have included a 
small patch to update your documentation with AWS-LC as an option and I 
attempted to add AWS-LC to your CI. I need a little help figuring out how to 
test that part. Lastly from your excellent contributing guide I am not 
subscribed so I would like to be cc’d on all responses.

Thanks, Andrew

[1] https://github.com/aws/aws-lc
[2] https://github.com/aws/aws-lc/pull/1054
[3] https://github.com/aws/aws-lc/pull/1071
[4] https://github.com/aws/aws-lc/pull/1083
[5] 
https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance
[6] 

Re: Old style OCSP not working anymore?

[Sander Klein]

On 2023-07-17 15:17, William Lallemand wrote:

On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote:

Hi,

I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I 
couldn't

connect to any of the sites behind it.

While looking at the error it seems like OCSP is not working anymore.
Right now I have a setup in which I provision the certificates with 
the

corresponding ocsp file next to it. If this not supported anymore?


This is supposed to still be working, however we could have introduced
bugs when building the ocsp-update. Are you seeing errors during the
OCSP file loading?


I don't see any errors, not even when I start haproxy by hand with '-d'. 
It's just like the ocsp isn't used at al. Also started haproxy with 
strace attached and I see the ocsp files are loaded.


Regards,

Sander

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

[William Lallemand]

On Mon, Jul 17, 2023 at 05:56:15PM +0200, Илья Шипицин wrote:
> also, if "aws-lc" is somewhat very similar to openssl-1.1.1, we do not
> expect we'll catch a lot of build errors daily because we already run
> builds against openssl-1.1.1, maybe weekly CI would be enough.


a Weekly CI is good enough indeed, enough to monitor breakage and it
won't disturb us during development.


-- 
William Lallemand

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

[Илья Шипицин]

пн, 17 июл. 2023 г. в 11:58, William Lallemand :

> On Wed, Jul 12, 2023 at 12:26:06AM +, Hopkins, Andrew wrote:
> > Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC)
> > project [1]. Our goal is to improve the cryptography we use internally
> > at AWS and help our customers externally. In the spirit of helping
> > people use good crypto we know it’s important to make it easy to use
> > AWS-LC everywhere they use cryptography. This is why we are interested
> > in integrating AWS-LC into HAProxy.
> >
> > AWS-LC is a fork of BoringSSL which you already partially support. We
> > recently merged in several PRs (Full OCSP support [2] and custom
> > extension support [3]) to fully support HAProxy the same as OpenSSL.
> > To ensure we continue to support HAProxy long term we added HAProxy
> > built with AWS-LC to our CI [4].
> >
> > In our early testing we see modest improvements in overall throughput
> > when compared to OpenSSL 3.1 on x86 and arm CPUs. Following a similar
> > setup as this blog [5] I observe a small (~2.5%) increase in requests
> > per second for 5 kb requests on a C6i (x86) and C6g (arm) instance
> > using TLS 1.3 and AES 256 GCM. For both tests I used `taskset -c 2-47
> > ./h1load -e -ll -P -t 46 -s 30 -d 120 -c 500 https://[c6i or c6g
> > ip]:[aws-lc or openssl port]/?s=5k`.
> >
> > This small difference in this symmetric crypto workload comes down to
> > AWS-LC and OpenSSL having similar AES implementations. We observe
> > larger performance improvements with our micro-benchmarks for
> > algorithms related to the TLS handshake such as 15% reduction for ECDH
> > with P-256, and 40% reduction for P-521 on a C6i. This comes from our
> > s2n-bignum library[6], a formally verified bignum library with a focus
> > on performance and correctness.
> >
> > When built with AWS-LC all current regression tests pass. I have
> > included a small patch to update your documentation with AWS-LC as an
> > option and I attempted to add AWS-LC to your CI. I need a little help
> > figuring out how to test that part. Lastly from your excellent
> > contributing guide I am not subscribed so I would like to be cc’d on
> > all responses.
> >
> > Thanks, Andrew
> >
>
> Hello Andrew,
>
> That's interesting and we are open to new libraries that can give us a
> good alternative to OpenSSL.
>
> However the CI is becoming quite slow and we'd rather not add a new
> build for each push. I don't really like the fact that the patch is
> based on the git master for the push, the CI principally used to check
> if we didn't break anything in haproxy, so if the library keep changing
> during haproxy development it's more difficult to know if a breakage is
> because of haproxy or because of the library. We stopped building
> BoringSSL on the CI because of this, because there wasn't any clear
> maintainenance cycle and the library kept changing. It looks like you
> have real releases in awc-ls though.
>

BoringSSL is "rolling releases only" while aws-lc has stable releases.
there's work in progress how to cache aws-lc build (I guess only couple of
small issues still exist)

[PATCH] Minor: ssl: Build with new cryptographic library AWS-LC by
andrewhop · Pull Request #1 · andrewhop/haproxy (github.com)


I'm fine with either scheduled or "on push" CI checks, no particular
opinion from my side.

also, if "aws-lc" is somewhat very similar to openssl-1.1.1, we do not
expect we'll catch a lot of build errors daily because we already run
builds against
openssl-1.1.1, maybe weekly CI would be enough.



>
> What I suggest is that we create a scheduled build for aws-lc like we've
> done with
>
> https://github.com/haproxy/haproxy/blob/master/.github/workflows/openssl-nodeprecated.yml
> for example.
>
> This way we don't increase the CI build for each push, and using the
> master branch don't become a problem.


> Regards,
>
> --
> William Lallemand
>
>

Re: [PATCH 0/2] improve CI friendliness

[William Lallemand]

On Sat, Jul 15, 2023 at 12:00:47AM +0200, Ilya Shipitsin wrote:
> thanks to Andrew Hopkins from Amazon, we've learned that CI is already easy 
> to learn,
> however few things can be improved.
> 
> let us add naming convention inline comment, also if VTest fails, let is 
> highlight that.
> 
> Ilya Shipitsin (2):
>   CI: add naming convention documentation
>   CI: explicitely highlight VTest result section if there's something
> 
>  .github/matrix.py   | 18 +-
>  .github/workflows/vtest.yml |  1 +
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> -- 
> 2.40.1
> 
> 

Merged, thank you!

-- 
William Lallemand

Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

[William Lallemand]

On Mon, Jul 17, 2023 at 08:22:58AM -0500, Mariam John wrote:
> This is an implementation of feature request 
> [#2165](https://github.com/haproxy/haproxy/issues/2165),
> to get the EC curve name used during the key agreement in OpenSSL. This patch 
> includes the following
> changes:
> - new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the 
> curve name
> - doc changes to add description for the new sample fetch methods
> - a new regression test 'ssl_curve_name` to test the new sample fetch 
> methods. (Tested it with the 
>   CI against my fork using github actions and it passes with all supported 
> SSL libraries and OpenSSL versions)
> 
> This uses the function `SSL_get_negotiated_group` method available from the 
> OpenSSLv3 release.
> 
> Thank you.
> 
> Mariam John (1):
>   MEDIUM: ssl: new sample fetch method to get curve name
> 
>  doc/configuration.txt| 10 +++
>  reg-tests/ssl/ssl_curve_name.vtc | 51 
>  src/ssl_sample.c | 46 
>  3 files changed, 107 insertions(+)
>  create mode 100644 reg-tests/ssl/ssl_curve_name.vtc
> 

Great, thank you!

I just pushed your patch in the master branch.

-- 
William Lallemand

Re: Wierd issue with OCSP updating

[William Lallemand]

On Thu, Jul 13, 2023 at 07:10:29PM -0600, Shawn Heisey wrote:
> On 7/13/23 15:00, Cyril Bonté wrote:
> > Hi Shawn,
> >
> > Le 13/07/2023 à 18:48, Shawn Heisey a écrit :
> >> Looks like on my last edit I deleted it and didn't add it to 
> >> defaults, so I was wrong in what I said.  It throws a different error 
> >> when added to defaults: 
> >> Because it should be in the global section, not the defaults one ;) 
> 
> It didn't work in global either.  It threw an error message that I did 
> not understand at first.
> 
> After a little poking around with google, I added this section to the 
> config (with the ipv4 resolver setting in global) and that made it work:
> 
> resolvers default
>      nameserver dns1 127.0.0.1:53
>      nameserver dns2 8.8.8.8:53
>      accepted_payload_size 8192 # allow larger DNS payloads
> 
> Further investigation revealed that systemd-resolved was not setting 
> /etc/resolv.conf to the usual symlink.  It was a real zero byte file.
> 
> Fixing that so it is a symlink to 
> |/run/systemd/resolve/stub-resolv.conf|and commenting the new resolvers 
> section in haproxy.cfg has completely fixed the issue.
> 
> I didn't think it was a bug in haproxy, but couldn't figure out why it 
> was misbehaving.  Now I know it was a problem with /etc/resolv.conf.  I 
> didn't think to look there because I could connect to things by name 
> from the shell prompt, so I assumed everything was good.
> 
> Thanks,
> Shawn

Indeed, haproxy creates a 'default' resolvers section this way if you
don't create one yourself:

resolvers default
parse-resolv-conf


-- 
William Lallemand

Re: Wierd issue with OCSP updating

[William Lallemand]

On Thu, Jul 13, 2023 at 10:48:41AM -0600, Shawn Heisey wrote:
> On 7/12/23 04:13, Remi Tricot-Le Breton wrote:
> > On 11/07/2023 22:22, Shawn Heisey wrote:
> >> On 7/11/23 01:30, Remi Tricot-Le Breton wrote:
> >> That directive didn't work in "global" but it was accepted when I 
> >> moved it to "defaults".  But it didn't change the behavior.  IPv6 is 
> >> completely disabled on the server.
> > 
> > Didn't work as in an error was raised ? I have a local configuration 
> > file with this option in the global section and it seems to work fine.
> 
> It failed the config check that is done by the systemd service before 
> restarting.  It seems to indicate I am missing additional config that it 
> needs.
> 
> elyograg@bilbo:~$ sudo haproxy -dD -c -f /etc/haproxy/haproxy.cfg
> [NOTICE]   (521767) : haproxy version is 2.8.1
> [NOTICE]   (521767) : path to executable is /usr/local/sbin/haproxy
> [ALERT](521767) : config : Proxy '': Can't find 
> resolvers section 'default' for do-resolve action.
> [ALERT](521767) : config : Proxy '': Can't find 
> resolvers section 'default' for do-resolve action.
> [DIAG] (521767) : config : Generating a random cluster secret. You 
> should define your own one in the configuration to ensure consistency 
> after reload/restart or across your whole cluster.
> [ALERT](521767) : config : Fatal errors found in configuration.
> 

Hm we should probably improve the errors here, it seems to happen
because you set an httpclient option in your global section but your
/etc/resolv.conf wasn't available. I'll definitively try to improve
this.

> > You can use the "httpclient" CLI command this way:
> > echo "expert-mode on; httpclient GET 
> > http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D;
> >  | socat  -
> 
> I get an error from that, and it makes no sense to me.
> 
> 
> elyograg@bilbo:~$ echo "expert-mode on; httpclient GET 
> http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D;
>  
> | sudo socat /etc/haproxy/stats.socket -
> Permission denied
> 
> This command is restricted to expert mode only.
> 
> 

It happens because you don't have the right level on your stats socket,
expert-mode needs an admin level.

-- 
William Lallemand

[PATCH 1/1] MEDIUM: ssl: new sample fetch method to get curve name

[Mariam John]

Adds a new sample fetch method to get the curve name used in the
key agreement to enable better observability. In OpenSSLv3, the function
`SSL_get_negotiated_group` returns the NID of the curve and from the NID,
we get the curve name by passing the NID to OBJ_nid2sn. This was not
available in v1.1.1. SSL_get_curve_name(), which returns the curve name
directly was merged into OpenSSL master branch last week but will be available
only in its next release.
---
 doc/configuration.txt| 10 +++
 reg-tests/ssl/ssl_curve_name.vtc | 51 
 src/ssl_sample.c | 46 
 3 files changed, 107 insertions(+)
 create mode 100644 reg-tests/ssl/ssl_curve_name.vtc

diff --git a/doc/configuration.txt b/doc/configuration.txt
index ccc736f9b..7b951f985 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -20722,6 +20722,11 @@ ssl_bc_client_random : binary
   sent using ephemeral ciphers. This requires OpenSSL >= 1.1.0, or BoringSSL.
   It can be used in a tcp-check or an http-check ruleset.
 
+ssl_bc_curve : string
+  Returns the name of the curve used in the key agreement when the outgoing
+  connection was made over an SSL/TLS transport layer. This requires 
+  OpenSSL >= 3.0.0.
+
 ssl_bc_err : integer
   When the outgoing connection was made over an SSL/TLS transport layer,
   returns the ID of the last error of the first error stack raised on the
@@ -21057,6 +21062,11 @@ ssl_fc_cipherlist_xxh : integer
   "tune.ssl.capture-buffer-size" is set greater than 0, however the hash take
   into account all the data of the cipher list.
 
+ssl_fc_curve : string
+  Returns the name of the curve used in the key agreement when the incoming
+  connection was made over an SSL/TLS transport layer. This requires
+  OpenSSL >= 3.0.0.
+
 ssl_fc_ecformats_bin : binary
   Return the binary form of the client hello supported elliptic curve point
   formats. The maximum returned value length is limited by the shared capture
diff --git a/reg-tests/ssl/ssl_curve_name.vtc b/reg-tests/ssl/ssl_curve_name.vtc
new file mode 100644
index 0..a285a8f86
--- /dev/null
+++ b/reg-tests/ssl/ssl_curve_name.vtc
@@ -0,0 +1,51 @@
+#REGTEST_TYPE=devel
+
+varnishtest "Test the ssl_fc_curve/ssl_bc_curve sample fetches"
+feature cmd "$HAPROXY_PROGRAM -cc 'feature(OPENSSL) && 
ssllib_name_startswith(OpenSSL) && openssl_version_atleast(3.0.0)'"
+feature ignore_unknown_macro
+
+server s1 -repeat 3 {
+rxreq
+txresp
+} -start
+
+haproxy h1 -conf {
+global
+tune.ssl.default-dh-param 2048
+tune.ssl.capture-buffer-size 1
+crt-base ${testdir}
+
+defaults
+mode http
+option httplog
+log stderr local0 debug err
+option logasap
+timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
+timeout client  "${HAPROXY_TEST_TIMEOUT-5s}"
+timeout server  "${HAPROXY_TEST_TIMEOUT-5s}"
+
+
+listen clear-lst
+bind "fd@${clearlst}"
+balance roundrobin
+http-response add-header x-ssl-bc-curve-name %[ssl_bc_curve]
+server s1 "${tmpdir}/ssl.sock" ssl verify none crt 
${testdir}/client.ecdsa.pem
+
+listen ssl-lst
+mode http
+http-response add-header x-ssl-fc-curve-name %[ssl_fc_curve]
+bind "${tmpdir}/ssl.sock" ssl crt ${testdir}/common.pem ca-file 
${testdir}/set_cafile_rootCA.crt verify optional curves X25519:P-256:P-384
+
+   server s1 ${s1_addr}:${s1_port}
+} -start
+
+
+client c1 -connect ${h1_clearlst_sock} {
+txreq
+rxresp
+expect resp.status == 200
+expect resp.http.x-ssl-fc-curve-name == "X25519"
+expect resp.http.x-ssl-bc-curve-name == "X25519"
+
+} -run
+
diff --git a/src/ssl_sample.c b/src/ssl_sample.c
index 5aec97fef..d7a7a09f9 100644
--- a/src/ssl_sample.c
+++ b/src/ssl_sample.c
@@ -1304,6 +1304,46 @@ smp_fetch_ssl_fc_is_resumed(const struct arg *args, 
struct sample *smp, const ch
return 1;
 }
 
+/*
+ * string, returns the EC curve used for key agreement on the
+ * front and backend connection.
+ *
+ * The function to get the curve name (SSL_get_negotiated_group) is only 
available
+ * in OpenSSLv3 onwards and not for previous versions.
+ */
+#if (HA_OPENSSL_VERSION_NUMBER >= 0x300fL)
+static int
+smp_fetch_ssl_fc_ec(const struct arg *args, struct sample *smp, const char 
*kw, void *private)
+{
+struct connection *conn;
+SSL *ssl;
+int nid;
+
+if (obj_type(smp->sess->origin) == OBJ_TYPE_CHECK)
+conn = (kw[4] == 'b') ? sc_conn(__objt_check(smp->sess->origin)->sc) : 
NULL;
+else
+conn = (kw[4] != 'b') ? objt_conn(smp->sess->origin) :
+smp->strm ? sc_conn(smp->strm->scb) : NULL;
+
+ssl = ssl_sock_get_ssl_object(conn);
+if (!ssl)
+return 0;
+
+nid = SSL_get_negotiated_group(ssl);
+if (!nid)
+return 0;
+smp->data.u.str.area = (char *)OBJ_nid2sn(nid);
+if (!smp->data.u.str.area)
+return 0;
+
+

[PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

[Mariam John]

This is an implementation of feature request 
[#2165](https://github.com/haproxy/haproxy/issues/2165),
to get the EC curve name used during the key agreement in OpenSSL. This patch 
includes the following
changes:
- new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the curve 
name
- doc changes to add description for the new sample fetch methods
- a new regression test 'ssl_curve_name` to test the new sample fetch methods. 
(Tested it with the 
  CI against my fork using github actions and it passes with all supported SSL 
libraries and OpenSSL versions)

This uses the function `SSL_get_negotiated_group` method available from the 
OpenSSLv3 release.

Thank you.

Mariam John (1):
  MEDIUM: ssl: new sample fetch method to get curve name

 doc/configuration.txt| 10 +++
 reg-tests/ssl/ssl_curve_name.vtc | 51 
 src/ssl_sample.c | 46 
 3 files changed, 107 insertions(+)
 create mode 100644 reg-tests/ssl/ssl_curve_name.vtc

-- 
2.39.2 (Apple Git-143)

RE: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

[Mariam John]

Indeed I did. I send the patch from the old folder. I apologize for the mistake 
on my part. I am sending the right one now.

Thank you for your patience.

Regards,
Mariam.


From: William Lallemand 
Date: Monday, July 17, 2023 at 4:28 AM
To: Mariam John 
Cc: haproxy@formilux.org , eb...@haproxy.com 

Subject: [EXTERNAL] Re: [PATCH 0/1] Implement new sample fetch method to get 
the curve name used in key agreement
On Fri, Jul 14, 2023 at 02:59:52AM -0500, Mariam John wrote:
> This is an implementation of feature request 
> [#2165](https://github.com/haproxy/haproxy/issues/2165 ),
> to get the EC curve name used during the key agreement in OpenSSL. This patch 
> includes the following
> changes:
> - new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the 
> curve name
> - doc changes to add description for the new sample fetch methods
> - updates the existing regression tests to test the new sample fetch methods
>
> This uses the function `SSL_get_negotiated_group` method available from the 
> OpenSSLv3 release.
>
> Thank you.
>
> Mariam John (1):
>   MEDIUM: ssl: new sample fetch method to get curve name
>
>  doc/configuration.txt|  8 +
>  reg-tests/ssl/ssl_client_samples.vtc |  2 ++
>  reg-tests/ssl/ssl_curves.vtc |  4 +++
>  src/ssl_sample.c | 46 
>  4 files changed, 60 insertions(+)
>

Hello Mariam,

It seems like you sent us the previous patch by mistake?

I pushed the patch in a separate branch to run the CI on it:
https://github.com/haproxy/haproxy/actions/runs/5573879545/jobs/10181759082

Regards,

--
William Lallemand

Re: Old style OCSP not working anymore?

[William Lallemand]

On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote:
> Hi,
> 
> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't 
> connect to any of the sites behind it.
> 
> While looking at the error it seems like OCSP is not working anymore. 
> Right now I have a setup in which I provision the certificates with the 
> corresponding ocsp file next to it. If this not supported anymore?
> 
> Regards,
> 
> Sander
> 

This is supposed to still be working, however we could have introduced
bugs when building the ocsp-update. Are you seeing errors during the
OCSP file loading?

-- 
William Lallemand

Re: Compiling HAProxy 2.8.1 with WolfSSL 5.6.3 yields errors about OCSP

[William Lallemand]

On Fri, Jul 14, 2023 at 11:01:16PM +0200, Marcel Menzel wrote:
> Hello List,
> 
> Trying to compile HAProxy version 2.8.1 with WolfSSL 5.6.3 results in 
> the following error:
> 
> src/ssl_sock.c: In function ‘ssl_sock_load_ocsp’:
> src/ssl_sock.c:1117:9: error: unknown type name ‘tlsextStatusCb’
>   1117 | tlsextStatusCb callback;
>    | ^~
> make: *** [Makefile:998: src/ssl_sock.o] Error 1
> make: *** Waiting for unfinished jobs
> 
> In my makefile / Arch Linux PKGBUILD I have the following:
> 
>    unset CFLAGS
>    unset CXXFLAGS
>    unset LDFLAGS
> 
>    export CFLAGS="$CFLAGS -fwrapv"
> 
>    make \
>      CFLAGS="$CFLAGS" \
>      LDFLAGS="$LDFLAGS" \
>      CPU=generic \
>      TARGET=linux-glibc \
>      USE_GETADDRINFO=1 \
>      USE_LUA=1 \
>      USE_OPENSSL_WOLFSSL=1 \
>      USE_PCRE2=1 USE_PCRE2_JIT=1 \
>      USE_PROMEX=1 \
>      USE_SYSTEMD=1 \
>      USE_ZLIB=1
> 
> Using Kernel 6.1.38-hardened1 if of interest. Am I missing something here?
> 
> 
>      - Marcel

Hello,

WolfSSL 5.6.3 and HAProxy 2.8.1 are compatible with each other, however
you need to compile wolfssl and haproxy the right way.

You should probably try building haproxy without reseting "LDFLAGS" and
"CFLAGS" first, and then add "SSL_LIB" and "SSL_INC" with the right
wolfssl path.

Please follow the build instruction in the INSTALL file, there are
also instructions regarding how to build WolfSSL with haproxy
compatibility.

Regards,

-- 
William Lallemand

RE: School Districts Contacts 2023

[Natalie Harper]

Hi there,
We are excited to offer you a comprehensive email list of school districts that 
includes key contact information such as phone numbers, email addresses, 
mailing addresses, company revenue, size, and web addresses. Our databases also 
cover related industries such as:

  *   K-12 schools
  *   Universities
  *   Vocational schools and training programs
  *   Performing arts schools
  *   Fitness centers and gyms
  *   Child care services and providers
  *   Educational publishers and suppliers
If you're interested, we would be happy to provide you with relevant counts and 
a test file based on your specific requirements.
Thank you for your time and consideration, and please let us know if you have 
any questions or concerns.

Best regards,

Natalie Harper





To remove from this mailing reply with the subject line " LEAVE US".

Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC

[William Lallemand]

On Wed, Jul 12, 2023 at 12:26:06AM +, Hopkins, Andrew wrote:
> Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC)
> project [1]. Our goal is to improve the cryptography we use internally
> at AWS and help our customers externally. In the spirit of helping
> people use good crypto we know it’s important to make it easy to use
> AWS-LC everywhere they use cryptography. This is why we are interested
> in integrating AWS-LC into HAProxy.
> 
> AWS-LC is a fork of BoringSSL which you already partially support. We
> recently merged in several PRs (Full OCSP support [2] and custom
> extension support [3]) to fully support HAProxy the same as OpenSSL.
> To ensure we continue to support HAProxy long term we added HAProxy
> built with AWS-LC to our CI [4].
> 
> In our early testing we see modest improvements in overall throughput
> when compared to OpenSSL 3.1 on x86 and arm CPUs. Following a similar
> setup as this blog [5] I observe a small (~2.5%) increase in requests
> per second for 5 kb requests on a C6i (x86) and C6g (arm) instance
> using TLS 1.3 and AES 256 GCM. For both tests I used `taskset -c 2-47
> ./h1load -e -ll -P -t 46 -s 30 -d 120 -c 500 https://[c6i or c6g
> ip]:[aws-lc or openssl port]/?s=5k`.
> 
> This small difference in this symmetric crypto workload comes down to
> AWS-LC and OpenSSL having similar AES implementations. We observe
> larger performance improvements with our micro-benchmarks for
> algorithms related to the TLS handshake such as 15% reduction for ECDH
> with P-256, and 40% reduction for P-521 on a C6i. This comes from our
> s2n-bignum library[6], a formally verified bignum library with a focus
> on performance and correctness.
> 
> When built with AWS-LC all current regression tests pass. I have
> included a small patch to update your documentation with AWS-LC as an
> option and I attempted to add AWS-LC to your CI. I need a little help
> figuring out how to test that part. Lastly from your excellent
> contributing guide I am not subscribed so I would like to be cc’d on
> all responses. 
> 
> Thanks, Andrew
> 

Hello Andrew,

That's interesting and we are open to new libraries that can give us a
good alternative to OpenSSL.

However the CI is becoming quite slow and we'd rather not add a new
build for each push. I don't really like the fact that the patch is
based on the git master for the push, the CI principally used to check
if we didn't break anything in haproxy, so if the library keep changing
during haproxy development it's more difficult to know if a breakage is
because of haproxy or because of the library. We stopped building
BoringSSL on the CI because of this, because there wasn't any clear
maintainenance cycle and the library kept changing. It looks like you
have real releases in awc-ls though.

What I suggest is that we create a scheduled build for aws-lc like we've
done with
https://github.com/haproxy/haproxy/blob/master/.github/workflows/openssl-nodeprecated.yml
for example.

This way we don't increase the CI build for each push, and using the
master branch don't become a problem.

Regards,

-- 
William Lallemand

Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement

[William Lallemand]

On Fri, Jul 14, 2023 at 02:59:52AM -0500, Mariam John wrote:
> This is an implementation of feature request 
> [#2165](https://github.com/haproxy/haproxy/issues/2165),
> to get the EC curve name used during the key agreement in OpenSSL. This patch 
> includes the following
> changes:
> - new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the 
> curve name
> - doc changes to add description for the new sample fetch methods
> - updates the existing regression tests to test the new sample fetch methods
> 
> This uses the function `SSL_get_negotiated_group` method available from the 
> OpenSSLv3 release. 
> 
> Thank you.
> 
> Mariam John (1):
>   MEDIUM: ssl: new sample fetch method to get curve name
> 
>  doc/configuration.txt|  8 +
>  reg-tests/ssl/ssl_client_samples.vtc |  2 ++
>  reg-tests/ssl/ssl_curves.vtc |  4 +++
>  src/ssl_sample.c | 46 
>  4 files changed, 60 insertions(+)
> 

Hello Mariam,

It seems like you sent us the previous patch by mistake?

I pushed the patch in a separate branch to run the CI on it:
https://github.com/haproxy/haproxy/actions/runs/5573879545/jobs/10181759082

Regards,

-- 
William Lallemand