This way we will force the adoption of FIPS compliant cloudflared without having
to handle the transition for systems that already have it installed (since we
were previously using new artifacts with fips suffix) nor without having to
segregate the resulting binary name (since we were always generating a binary
just called cloudflared from the unpacked debian archive to avoid having to change
any automation that assumes the binary to be called just that).
This changes existing Makefile targets to make it obvious that they are
used to publish debian packages for internal Cloudflare usage. Those are
now FIPS compliant, with no alternative provided. This only affects amd64
builds (and we only publish internally for Linux).
This new Makefile target is used by all internal builds (including nightly
that is used for e2e tests).
Note that this Makefile target renames the artifact to be just `cloudflared`
so that this is used "as is" internally, without expecting people to opt-in
to the new `cloudflared-fips` package (as we are giving them no alternative).
This is a cherry-pick of 157f5d1412
followed by build/CI changes so that amd64/linux FIPS compliance is
provided by new/separate binaries/artifacts/packages.
The reasoning being that FIPS compliance places excessive requirements
in the encryption algorithms used for regular users that do not care
about that. This can cause cloudflared to reject HTTPS origins that
would otherwise be accepted without FIPS checks.
This way, by having separate binaries, existing ones remain as they
were, and only FIPS-needy users will opt-in to the new FIPS binaries.
This reverts commit 157f5d1412.
FIPS compliant binaries (for linux/amd64) are causing HTTPS origins to not
be reachable by cloudflared in certain cases (e.g. with Let's Encrypt certificates).
Origins that are not HTTPS for cloudflared are not affected.
Creates an abstraction over UDP Conn for origin "connection" which can
be useful for future support of complex protocols that may require
changing ports during protocol negotiation (eg. SIP, TFTP)
In addition, it removes a dependency from ingress on connection package.
When building the docker image, this `-dev` suffix is being added to the
cloudflared binary version.
The reason must be that there's some file, which is tracked by git, and
that is modified during that build.
It's not clear which file is it. But, at the same time, it's not clear what
advantage this `-dev` suffix is bringing. So we're simply removing it so that
we generate proper versions (so that our tracking/observability can correctly
aggregate these values).
- Refactors some h2mux specific logic from connection/header.go to connection/h2mux_header.go
- Do the same for the unit tests
- Add a non-h2mux "is control response header" function (we don't need one for the request flow)
- In that new function, do not consider "content-length" as a control header
- Use that function in the non-h2mux flow for response (and it will be used also in origintunneld)
When forwarding an UA-less request to the origin server cloudflared insert the default golang http User-Agent, this is unexpected and can lead to issue.
This simple fix force setting the UA to the empty string when it isn't originaly provided.
Connections from cloudflared to Cloudflare edge are long lived and may
break over time. That is expected for many reasons (ranging from network
conditions to operations within Cloudflare edge). Hence, logging that as
Error feels too strong and leads to users being concerned that something
is failing when it is actually expected.
With this change, we wrap logging about connection issues to be aware
of the tunnel state:
- if the tunnel has no connections active, we log as error
- otherwise we log as warning
Nuno Diegues
João Oliveirinha
cthuang
Igor Postelnik
Silver
Yuwei B
Benoit Plessis
Dimitris Apostolou
Sudarsan Reddy