We have a supplier provided REST API that doesn't support HTTPS (only HTTP). Is there a way to secure the outbound REST PUTs (to AWS) using HTTPS? We were considering using STunnel but this doesn't meet our internal InfoSec requirements. Would it be possible to put an IIS reverse proxy in and secure the outbound traffic from there?
Related
I cannot for the life of me get the AWS API Gateway HTTP Proxy to work, i.e. redirect http://<my-domain>.com to https://<my-domain>.com. Here is how I set it up:
Using the Test functionality on the ANY method inside the resource works. But if I simply do curl http://<my-domain>.com or run http://<my-domain>.com in Chrome, it fails to connect; https://<my-website>.com works just fine. I'm driving myself crazy trying to figure out what I'm missing here; it seems like it should just redirect http://<my-domain>.com to https://<my-domain>.com, but it doesn't (even on different devices).
So, it turns out that API Gateway's HTTP Proxy allows HTTPS traffic to go to an HTTP endpoint, but not the reverse. In fact, API Gateway won't even establish a connection on port 80; from the FAQ:
Q: Can I create HTTPS endpoints?
Yes, all of the APIs created with Amazon API Gateway expose HTTPS
endpoints only. Amazon API Gateway does not support unencrypted (HTTP)
endpoints.
API Gateway doesn't support unencrypted HTTP traffic. Here are the possible options you can do to secure your website:
If you have access to the server that hosts the website, install an SSL certificate to the webserver.
If the website is hosted on EC2, you can set up a load balancer and let it do the SSL termination.
Question
Is there a specific reason why API Gateway requires the HTTP/S client to support SNI?
Which AWS document clearly states the SNI requirement?
About Question 2
I believe SNI is an extension to TLS and TLS version 1.2 does not require to support SNI as far as I looked into RFC. TLS 1.3 requires it as mandatory but it looks AWS API Gateway has not adopted 1.3 yet as per the AWS document Supported SSL/TLS Protocols and Ciphers for Regional, Private, and WebSocket API Endpoints in API Gateway.
Hence, I suppose enforcing SNI, if AWS API Gateway actually does so, seems to be AWS specific requirement or limitation to be clearly noted, but so far I could not find the AWS documentation stating as such.
Hence I believe there should be an AWS documentation which states below, but please correct if wrong.
HTTP/S client to use API gateway must support SNI
For SNI unsupported HTTP/S client, use CloudFront (or other ways if available) and do not forward HOST header.
References
Unable to invoke AWS API Gateway GET URL with GPRS connection
API Gateway requires a https connection with a client that support server name indicator (SNI)
How do you add CloudFront in front of API Gateway
You can indeed put CF dist in front of APIG, the trick is to force HTTPS only "Viewer Protocol Policy" AND to NOT forward the HOST header because APIG needs SNI.
As far as I know SNI is not required for the API Gateway, this is a configuration option, but not a requirement.
The documentation I once used to understand a similar scenario clearly states that SNI is an option, but a dedicated IP address can be used to support users that can't use a modern TLS client (browser) which support SNI.
Server Name Indication (SNI) is one way to associate a request with a
domain. Another way is to use a dedicated IP address. If you have
users who can't upgrade to a browser or client released after 2010,
you can use a dedicated IP address to serve HTTPS requests.
Per your question I will assume your API Gateway is configured to use SNI with CloudFront, since as also described in the following API Gateway documentation:
API Gateway supports edge-optimized custom domain names by leveraging
Server Name Indication (SNI) on the CloudFront distribution.
I've added certificate with custom domain name map in AWS API gateway but it allows HTTP automatically, how can I block normal HTTP and only allows HTTPS?
All API Gateway APIs are fronted with a CloudFront distribution. Each of these CloudFront distributions (whether it's a Custom Domain like yours or the default *.execute-api distribution) is configured to redirect all HTTP requests to HTTPS. Although CloudFront has the option to strictly require HTTPS and return 403 on HTTP requests we currently don't expose this option for simplicity.
If you feel you have valid use case for requiring HTTPS without a redirect please open a support ticket and the team can evaluate your request.
I am trying to access a secured WAS URL via the Secure Gateway. I can access an unsecured page via HTTP. When I set the Secure Gateway Destination to HTTPS and try to access the secured page (requires a userid/password), the connection fails.
Last year I was told that HTTPS was not supported. However, I think that I just don't know how to configure the Secure Gateway to do it now.
In order for HTTPS to be in use on both sides of the connection (app to Secure Gateway Server, and Secure Gateway Client to on-premises resource), the protocol should be HTTPS (which it sounds like you have) and you should also enable Destination-side TLS under the Advanced options panel of the destination. This will cause the connection being made from the Secure Gateway Client to the on-premises resource to be HTTPS rather than HTTP.
I'm building a RESTful API which is only accessible by TLS. Where should SSL connection be implemented?
by RESTful API itself, my API is written in golang, which handles SSL easily.
by a SSL reverse proxy, here I'm using nginx.
I would prefer 2nd approach because nginx handles caching and static deliveries better.
Should I implement my API HTTP-only now? In my opinion the system is secure, as long as nginx the reverse proxy is serving SSL only and my API exposes itself to nginx only.
I'm not sure if there is a 3rd approach, while I keep my API SSL only and nginx passes through all requests transparently.
TL;DR: I will choose between the 2nd or 3rd option, depending on the scenario. If you want to publish the API on Internet, never opt for the first one.
The most secure option is the third one: implement your API to allow SSL connections only, and publish to Internet using a reverse proxy anyway.
The pros are the communication with your API will be secure even for internal connections. That will give you protection from internal attackers. The cons are the extra processing load on your server to manage the SSL security and that can impact on the performance.
Anyway, you should look for cost-benefit. That's the reason why it will depend on the scenario. For example, if your API will not be accessed by internal users, but only for internal services, and the load on the server is heavy, you can consider the 2nd approach: plain HTTP por internal communications and SSL termination for Internet.