OCSP responder errors without Host header

Feature Requests
1

We have about 600 Polycom phones that are transitioning to use SIP over TLS instead of UDP. Our voice servers use certificates from LE, and all is going well – except OCSP requests from the phones.

I believe the problem is that the phones are not sending a Host header in the HTTP request. Whatever the cause, the request is failing. The certificates are still accepted, but it's causing considerable noise in our logging system and obviously reduces the security of things.

Assuming that the missing Host header is the problem, is it possible to get this working on your servers? Obviously we can't expect you to jump at the chance of an infrastructure change like this. But there's a better chance of it happening than Polycom responding to our requests, so we thought we'd ask!

Here's a sample request showing the 400 response from your servers:

00000000  50 4f 53 54 20 2f 20 48  54 54 50 2f 31 2e 30 0d   POST / H TTP/1.0.
00000010  0a 43 6f 6e 74 65 6e 74  2d 54 79 70 65 3a 20 61   .Content -Type: a
00000020  70 70 6c 69 63 61 74 69  6f 6e 2f 6f 63 73 70 2d   pplicati on/ocsp-
00000030  72 65 71 75 65 73 74 0d  0a 43 6f 6e 74 65 6e 74   request. .Content
00000040  2d 4c 65 6e 67 74 68 3a  20 38 35 0d 0a 0d 0a      -Length:  85....
0000004F  30 53 30 51 30 4f 30 4d  30 4b 30 09 06 05 2b 0e   0S0Q0O0M 0K0...+.
0000005F  03 02 1a 05 00 04 14 48  da c9 a0 fb 2b d3 2d 4f   .......H ....+.-O
0000006F  f0 de 68 d2 f5 67 b7 35  f9 b3 c4 04 14 14 2e b3   ..h..g.5 ........
0000007F  17 b7 58 56 cb ae 50 09  40 e6 1f af 9d 8b 14 c2   ..XV..P. @.......
0000008F  c6 02 12 04 51 f7 e8 d8  7f 5d 0d ca be 75 ba ac   ....Q... .]...u..
0000009F  3b 6a e1 63 a3                                     ;j.c.

    00000000  48 54 54 50 2f 31 2e 30  20 34 30 30 20 42 61 64   HTTP/1.0  400 Bad
    00000010  20 52 65 71 75 65 73 74  0d 0a 53 65 72 76 65 72    Request ..Server
    00000020  3a 20 41 6b 61 6d 61 69  47 48 6f 73 74 0d 0a 4d   : Akamai GHost..M
    00000030  69 6d 65 2d 56 65 72 73  69 6f 6e 3a 20 31 2e 30   ime-Vers ion: 1.0
    00000040  0d 0a 43 6f 6e 74 65 6e  74 2d 54 79 70 65 3a 20   ..Conten t-Type: 
    00000050  74 65 78 74 2f 68 74 6d  6c 0d 0a 43 6f 6e 74 65   text/htm l..Conte
    00000060  6e 74 2d 4c 65 6e 67 74  68 3a 20 32 30 39 0d 0a   nt-Lengt h: 209..
    00000070  45 78 70 69 72 65 73 3a  20 46 72 69 2c 20 32 33   Expires:  Fri, 23
    00000080  20 44 65 63 20 32 30 32  32 20 32 31 3a 34 36 3a    Dec 202 2 21:46:
    00000090  33 34 20 47 4d 54 0d 0a  44 61 74 65 3a 20 46 72   34 GMT.. Date: Fr
    000000A0  69 2c 20 32 33 20 44 65  63 20 32 30 32 32 20 32   i, 23 De c 2022 2
    000000B0  31 3a 34 36 3a 33 34 20  47 4d 54 0d 0a 43 6f 6e   1:46:34  GMT..Con
    000000C0  6e 65 63 74 69 6f 6e 3a  20 63 6c 6f 73 65 0d 0a   nection:  close..
    000000D0  0d 0a                                              ..
    000000D2  3c 48 54 4d 4c 3e 3c 48  45 41 44 3e 0a 3c 54 49   <HTML><H EAD>.<TI
    000000E2  54 4c 45 3e 49 6e 76 61  6c 69 64 20 55 52 4c 3c   TLE>Inva lid URL<
    000000F2  2f 54 49 54 4c 45 3e 0a  3c 2f 48 45 41 44 3e 3c   /TITLE>. </HEAD><
    00000102  42 4f 44 59 3e 0a 3c 48  31 3e 49 6e 76 61 6c 69   BODY>.<H 1>Invali
    00000112  64 20 55 52 4c 3c 2f 48  31 3e 0a 54 68 65 20 72   d URL</H 1>.The r
    00000122  65 71 75 65 73 74 65 64  20 55 52 4c 20 22 26 23   equested  URL "&#
    00000132  39 31 3b 6e 6f 26 23 33  32 3b 55 52 4c 26 23 39   91;no&#3 2;URL&#9
    00000142  33 3b 22 2c 20 69 73 20  69 6e 76 61 6c 69 64 2e   3;", is  invalid.
    00000152  3c 70 3e 0a 52 65 66 65  72 65 6e 63 65 26 23 33   <p>.Refe rence&#3
    00000162  32 3b 26 23 33 35 3b 39  26 23 34 36 3b 33 36 33   2;&#35;9 &#46;363
    00000172  33 66 34 31 38 26 23 34  36 3b 31 36 37 31 38 33   3f418&#4 6;167183
    00000182  31 39 39 34 26 23 34 36  3b 32 39 32 34 33 65 39   1994&#46 ;29243e9
    00000192  39 0a 3c 2f 42 4f 44 59  3e 3c 2f 48 54 4d 4c 3e   9.</BODY ></HTML>
    000001A2  0a                                                 .
1 Like
2

The Host header is mandatory for HTTP since the origin of the header in HTTP version 1.1. In essence, you're asking Let's Encrypt to support a protocol which is almost as ancient as the internet itself and has been superseded by a newer one more than 22 years ago.

Now, I'm not a Let's Encrypt staff member so I can't say anything about their choices of course, but if I were you, I'd allow for the possibility that Let's Encrypt is not going to add HTTP/1.0 support to their OCSP endpoints and look for alternative options.

As an alternative, maybe you could set up your own proxy that accepts HTTP/1.0 and sends the OCSP request through to the LE OCSP responder using HTTP/1.1? That would require some DNS snooping for r3.o.lencr.org though. Luckily the lencr.org zone doesn't have DNSSEC enabled, so should be feasible, if technically possible in your setup.

4 Likes
3

Yes it's a long shot, but like I said it's more likely than Polycom updating their phones' firmware. In Apache and Nginx it's a fairly minor configuration change to make one of your virtual hosts the default one. Obviously in an environment like this even a minor configuration change is rather a big deal. The alternative option is to just not use OCSP; proxying isn't an option since these phones are all at client sites.

4

Perhaps you can work around the problem by using OCSP stapling? Then your clients don't need to talk HTTP at all. It's also more load and privacy friendly.

9 Likes
5

Unfortunately, due to our CDN architecture, it's very unlikely we'll be able to support this case. The other suggestions in this thread are probably the way to go.

9 Likes
6

Unfortunately Asterisk doesn't offer a lot of flexibility in how it presents the certificates. Stapling is not an option.

7

Yeah I expected that would be the case

8

Or maybe even somehow teach the clients to do this?

... another weird possibility: ask the clients to set up the Polycom devices using a custom DNS server (that you run) which resolves r3.o.lencr.org to your own remote HTTP/1.0 -> HTTP/1.1 proxy?

4 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.