1

I have an Ocelot API gateway in front of all our microservices providing some form of an API. We also have some external services hosted in Azure, one which I figured I wanted to route through our API gateway. However, as the title says, when attempting to connect using https as the downstream scheme I get the following error message:

Error Code: ConnectionToDownstreamServiceError Message: Error connecting to downstream service, exception: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.IO.IOException: Cannot determine the frame size or a corrupted frame was received.
   at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter)
   at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
   at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Boolean async, Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)

Googling the inner exception leads to some posts suggesting that since .net 5.0 preview 6 the default tls version is determined by the operating system default which by now should probably be TLSv1.3. I believe Azure functions does not support TLSv1.3 yet and it appears that the downstream request from Ocelot does not fall back on TLSv1.2 when this is the case.

Attempting to run the request a number of other ways yields only success which leads me to believe that this is an issue specific to Ocelot. Running requests directly to the Azure resource via

  • Postman: succeeds. TLSv1.2 is used.
  • curl: succeeds. TLS1.2 is used here too.
  • GetAsync using HttpClient in C# (.net 5.0): succeeds.

Running curl with -v I can see that it attempts a handshake with TLSv1.3 first but then falls back to TLS1.2.

Can anyone confirm that the tls version is indeed the problem? And in that case is there any way to allow TLSv1.2 in an asp.net 5 ocelot API Gateway project?

Additional information:

  • Setting "DangerousAcceptAnyServerCertificateValidator": true does not resolve the issue
  • The gateway has no issues when using http as downstream scheme
niknoe
  • 323
  • 5
  • 14

1 Answers1

0

I have a similar environement where most of my Ocelot downstream requests are currently pointing to localhost microservices (in development). However i have rigged up an Azure Function (Http Trigger) that i deployed to Azure and therefore need Ocelot to route a downstream request to the external facing url.

What I can confirm is that my Ocelot environment is running on .NET Core 5.0 and am able to succesfully call the Azure Function and return the data to my front end Web App (upstream route)

I havent had to do anything different with Ocelot for it to work. Below is the snippet from the ocelot.json file

"Routes": [
    // ---------------------------------------------------
    // ---------- Azure Functions HTTP Triggers ----------
    // ---------------------------------------------------
    // ----------- Logs -----------
    {
      "DownstreamPathTemplate": "/api/logproperties",
      "DownstreamScheme": "https",
      "DownstreamHostAndPorts": [
        {
          "Host": "azurefunction-httpget-logproperties.azurewebsites.net",
          "Port": 443
        }
      ],
      "UpstreamPathTemplate": "/logs/logproperties",
      "UpstreamHttpMethod": [ "Get" ],
      "RouteIsCaseSensitive": false,
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "Bearer",
        "AllowedScopes": []
      }
    }
]

The actual url path for my function is shown below (obviously with the api key removed)

https://azurefunction-httpget-logproperties.azurewebsites.net/api/logproperties?code=<MyApiKeyHere>&containerName=ohiAppSource&logPropertyName=OhiAppSource

I was having issues intitially but after removing 'https://' from the string set for the "Host" in the Json config then it went through OK.

My Ocelot environement authenticates upstream requests (Client App --> Ocelot) using Microsoft Identity Web library so calling a function with a simple API key is not a security concern for me. But regardless of how you're securing the inbound side of ocelot, I dont think that would affect the issue you encountered. My solution is not promising a fix to your particular issue but it always helps to see a working configuration.

OJB1
  • 2,245
  • 5
  • 31
  • 63