Cloudflare Tunnels should support HTTP/2 over port 80

Zero Trust Cloudflare Tunnel
1

What is the name of the domain?

N/A

What is the issue you’re encountering

HTTP 1.1 is used, despite Apache 2 being configured to support h2c and curl confirming it works locally

What steps have you taken to resolve the issue?

Checked the documentation and saw that the option for HTTP/2 is only avaliable for HTTPS. It says this under TLS:

HTTP2 connection
Attempt to connect to origin using HTTP2. Origin must be configured as https.

However, HTTP/2 supports unecrypted connections too and if we are using a cloudflare tunnel for encryption already, there is no point in double encrypting the traffic. That would just slow things down. I suspect this results in a situation where double encryption is perversely faster than single encryption and if cloudflare tunnels work as advertised, the double encryption should be unnecessary and optimal performance would be achieved by using HTTP/2 over port 80.

Cloudflare needs a toggle for HTTP/2 on HTTP. Have it be the equivalent of setting curl’s --http2-prior-knowledge.

What are the steps to reproduce the issue?

  1. Make a local HTTP server that supports HTTP/2 on port 80 using h2c.
  2. Setup cloudflare tunnel to make it accessible via a domain/subdomain.
  3. Connect to it from the domain/subdomain.
  4. Observe in the server logs that HTTP 1.1 is being used.
  5. For good measure, run curl -sI --http2-prior-knowledge localhost and observe that your web server supports HTTP/2.
2

As an additional comment, having to worry about origin certificates is something that cloudflare tunnels really ought to enable people to avoid. It does do that, but only if you are okay not having the performance improvements of HTTP/2.

4

I would guess the cost of implementing h2c just for an “Allow h2c to origin when I use a tunnel” option and the interdependency that creates between two separate Cloudflare products is far higher than the little extra processor load of HTTPS and you generating an origin certificate, aside from it being in the general direction of less security, not more.

1 Like
6

@sjr If they have h2 implemented, which they do, implementing h2c should be fairly trivial. It is the same protocol with some minor differences since they do not have TLSv1.3 providing hints about protocol support.

Also, multiple encryption does not necessarily make things more secure. The encryption is using 128-bit AES. If you can break that once, you can break it twice. That is why encryption for banks jumps to 256-bit AES, not 130-bit AES. Off the top of my head, a hypothetical 130-bit encryption would be twice as hard to crack as 128-bit AES. The idea that this weakens anything is highly specious, as if you need to have the origin use encryption when using a cloudflare tunnel, the claims made by cloudflare about the security of cloudflare tunnels for serving origins would be wrong,

That said, please do not guess these things. Baseless speculation is not helpful to improving things.

Finally, there is a very good reason for not using certificates at the origin, which is to avoid inevitable issues due to expiry. Availability is part of the security triad and having certificates that expire on the origin jeopardize it.

8

Fun fact, if you encrypt something twice with certain ciphers, there is a combined encryption key that will decrypt both rounds at once, making multiple encryption with the same cipher pointless. Saying “it’s encrypted twice therefore it is safer” is a sure fire way to annoy anyone who understands anything about cryptography.

The only time you encrypt twice is if you are worried about flaws in the implementation such as side channel attacks in the algorithm’s implementation, and in that case, the second encryption must use an entirely different algorithm, ideally from an entirely different encryption libraries, in order to be worthwhile. A cloudflare tunnel with HTTPS inside with the encryption details left to chance does not meet that rigorous standard.

That only applies to concerns over side channel attacks and other weaknesses in how the implementation is done. It does not apply to concerns about 128-bit symmetric encryption being weak, which is what people seem to think would be addressed by multiple encryption.

People tried this with 56-bit encryption by doing the encryption thrice (3DES) and it turned out to be much weaker than the 112-bit strength people thought it had. That said, @sjr please keep your “less security” remarks to yourself. They are not just unhelpful, but outright wrong.

9

Certificate renewal is easily automated, or if using Cloudflare, use a 15-year origin certificate. The security trend generally is for encryption and short certificate lifetimes. You are swimming against the current.

How is HTTP/2 inside a Cloudflare tunnel less secure than just a Cloudflare tunnel?

:grinning:
/goes back to day job

If you want to propose “h2c over tunnel” option, you can ask for it as a feature request here.

2 Likes
13

@sjr There already is encryption provided by the cloudflare tunnel. Doing it twice is wasteful and gives questionable benefits. Cryptographers generally recommend not doing this because it gives almost no theoretical improvement and hurts performance far more than just going to a higher encryption level like 256-bit.

I could say more, but telling me to post to request the feature I just posted to request is as helpful as telling me that tautologies are tautologies. You are wasting both my time and your time. If you want to learn about how cryptography works and how to use it properly, there are more efficient ways than having me spoon feed you the answers. Just being told the answers without any need for thought on your part is a way to ensure you do not learn (otherwise just being told what words in Chinese mean would enable us all to speak Chinese).

15

Type of feedback

This site

Request

I posted a feature request in what I now know to be the wrong forum. Someone replied with patently wrong remarks, so I corrected him. The topic was locked and his wrong reply was marked as correct.

He posted baseless speculation (which he admitted by saying it was a guess) and a technically wrong remark that not encrypting twice weakened security. Doing encryption twice is well known to be an ineffective strategy for increasing the strength of encryption:

The meet in the middle attack reduces the improvement of applying 128-bit encryption twice to 129-bit. However, in some cases, double encryption yields no improvement in encryption at all:

I know that encrypt everything is the trend and I acknowledge it as a good idea. However, when you use a cloudflare tunnel, you already are encrypting everything. Doing it again does not appreciably increase security unless you use a longer key size.

With that explanation out of the way, please unmark that reply as the solution. If that individual’s replies are to be marked as anything, they should be marked with a label saying that they are incorrect and no one should listen to them. I do not seriously suggest this (as it is punishing ignorance), but I do want his specious comment to be unmarked as a solution.

16

Really?

Following this logic, you may as well not even use passwords at all, as people will inevitabley lock themselves out :smiley:

17

@GeorgeAppiah I cannot reply to locked threads and I do not know how you can, so I will reply here:

The fact that I am not asking for the ability to have unencrypted origin pulls over a cloudflare tunnel, but for cloudflare to make them faster makes the conversation of whether cloudflare should permit unencrypted origin pulls to avoid certificate expiry moot. They already permit it, and they do not even require a cloudflare tunnel to be used when they permit it, as they will happily pull from unencrypted web servers on the open internet. To be clear, this means the false analogy of users forgetting passwords is pointless. Not only is it pointless, but it is also a strawman argument against “cloudflare should allow unencrypted origin pulls”.

Cloudflare gives a cryptographic token for cloudflared to use. It has no expiration date and there is no forgetting it since a human is not entering it more than once. This has nothing to do with passwords. Hence why any analogy with passwords is a false analogy.

That said, I am a huge fan of eliminating passwords. I personally use public key based authentication wherever I can. My home wifi even uses EAP-TLS, which uses certificates in place of passwords. I dread the certificate expiry on that, but it actually has a point since by the time it expires, I really should replace the 2048-bit RSA keys being used by the certificates. By comparison, having to replace certificates that attackers cannot even see is pointless busy work.

As I am addressing your strawman here, I might as well address here the other strawman that @sjr made too, which involved double encryption weakening security. Like all strawman, it attacks an argument that I never made. In particular, I never said that double encrypting made encryption weaker. What I said was that double encryption had dubious security benefit. This is a well established fact, despite the idea of double encryption being so specious that plenty of well meaning people will think it is a good idea. That itself is despite legions of cryptographers saying otherwise with the exception of very specific scenarios (e.g. the NSA loves double encryption, but not for the reason average people think double encryption is a good idea; see the rule of 2). If you look at the stack exchange link, you will see the moderator of their crypto forum, who has actual credentials in the area, saying “largely so” when asked if multiple encryption is a stupid idea. He then proceeded to say roughly what I said, although he put it better than I did.

Finally, how can you reply to a locked thread? I can see why the thread was locked (it was filed in the wrong place and was off topic), but I cannot see why permitting people to reply to locked threads is a good idea.

18

It is a permission granted to Community MVPs, along with a handful of other moderation-esque capabilities.

2 Likes