Deno: std/http/server async iterable produces uncatchable errors

[kitsonk]

Because std/http/server.ts uses MuxAsyncIterator to serve up requests, any errors thrown there cannot be caught:

https://github.com/denoland/deno/blob/e34a3b61f449cf6197b6d701770a85d9205c2a7b/std/http/server.ts#L235-L239

The comments on MuxAsyncIterator make it clear that:

https://github.com/denoland/deno/blob/e34a3b61f449cf6197b6d701770a85d9205c2a7b/std/async/mux_async_iterator.ts#L9-L14

And in situations where you have a TLS connection where the browser rejects the certificate, you end up with something like this with Deno dumping and no way to recover:

error: Uncaught InvalidData: received corrupt message
    at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
    at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
    at async TLSListenerImpl.accept ($deno$/tls.ts:31:17)
    at async Server.acceptConnAndIterateHttpRequests (https://deno.land/[email protected]/http/server.ts:221:14)
    at async MuxAsyncIterator.callIteratorNext (https://deno.land/[email protected]/async/mux_async_iterator.ts:28:29)

We need a way to iterate that allows errors to be caught when iterating on HTTP server.

[lemaguilera]

For now I have been able to fix the problem using ubuntu firewall to allow https only from cloudflare servers (https://www.cloudflare.com/ips-v4), that solved the problem for now:

But it is necessary to be able to control that error so that the server continues working, because otherwise it would be like a ddos attack of a single request, either the attacker knows the IP of the server or it was a random visit with https

[Lonniebiz]

I submitted a passionate duplicate of this issue, that I just closed here: https://github.com/denoland/deno/issues/5931

I feel so strongly about this particular issue, that I've copied the full text of it below:

deno 1.0.0
v8 8.4.300
typescript 3.9.2

In Deno, is there already a way to override the pedantic scrutiny that often causes self-signed SSL certificates to be deemed "Bad Certificates"?

It seems that Deno security is so high that it blocks self-signed SSL certificates for vague reasons.

Not all SSL certificates should be subjected to international banking standards. There are valid reasons for creating self-signed SSL certificates with (practically) never expiring expiration dates. Too many security zealots automatically frown upon self-signed certificates, but hear me out.

Let's say you have two servers on a LAN, that serve each other with separate APIs. And, the only security you want, is to have encrypted data transfer between those two servers and nothing else. And, let's say these services (that these two servers provide) do NOT require internet to function.

Let me ask you this. Why the hell would you want to authenticate the SSL certificate with a 3rd party internet resource? The internet itself now becomes an unneeded external dependency that could potentially bring your service to a halt if the internet goes down (for a service that otherwise needs zero internet).

Well that's exactly what can happen, if deno has no way to override errors like this:

The above script and certificates are zipped here: testDeno.zip

The ssl certificates were generated with a command like this:
openssl req -nodes -new -x509 -keyout private.key -out server.cert -days 1825000 -subj "/C=US/ST=Texas/L=Houston/O=ChickenPeck Technologies/OU=Org/CN=localhost"

I suspect the certificate is bad due to the extremely far off date to which it expires. It would be nice if the error went into more detail about the exact reason the certificate is a "bad certificate".

However, even if that is the reason, I'd like the ability to override and ignore such pedantic scrutiny. I'm not going to use something that inconveniences me with a mandatory security level that is beyond what I want it to be.

Also, why would you want to schedule, on your calendar, a date (one year from now) when your service will crash due to an expired certificate? Instead, I want the service I created to live on without interruption, without any certificate update maintenance, until I decide I want to update it. As the developer of these services, I should be able to prioritize "uninterruptible" over "unnecessarily secure".

Is there already a way to override these type of certificate rejections? If not, I'm requesting it.

[pitust]

Another case is when you want to MITM some site that uses HTTPS. You can then point chrome/firefox/whatever at mitmproxy with ignore SSL errors enabled. (i ended up running HTTP instead of HTTPS at some super high closed port and wrote a proxy in Node.JS that i run as root)

[Lonniebiz]

@pitust In node.js I'm able to ignore SSL errors during fetch operations using an agent in node-fetch:
const httpsAgent = new https.Agent({ keepAlive: true, rejectUnauthorized: false });

[pitust]

well, i am talking about a server not a client. So no. I cannot use node-fetch as a server. (i think)

[Lonniebiz]

@pitust I see what you mean. In my case, my server does some fetching of its own, and that's how I get around those SSL errors for the fetch operations. Ultimately, we need the ability to override errors for serving and fetching.