CloudFlare workers fetch HTTPS works on workers.dev subdomain but not on own subdomain getting 525 error - ssl

I have a simple worker that just does a fetch against an HTTPS endpoint somewhere else.
The code is literally just:
return await fetch('https://something.com/someResource')
When I test locally (wrangler dev) and even publish to a workers subdomain this works fine. When I curl https://foo.bar.workers.dev/myEndpoint I get the same response as https://something.com/someResource.
However I want to run this from my own domain (managed through cloudflare) so the worker also has a route of foo.mydomain.com/* and a AAAA record to 100:: for foo as per CloudFlare docs. The DNS works fine the URL is reachable, but when I try to hit https://foo.mydomain.com/myEndpoint CloudFlare's worker logs show that the fetch behind the scenes fails with a 525 error (SSL Handshake fail).
Things I've tried based on some CloudFlare forum posts:
Add a page rule foo.mydomain.com/* -> SSL Mode: full since my overall SSL settings are set to flexible.
Set the host header in the fetch to the origin domain ( fetch(url, {headers: {'Host': 'something.com'}})
FYI, I don't control the origin server as it's an external API I work with.
How come the same request works from local and *.workers.dev but not my own domain?

Your page rule is not taking effect. The page rule is for foo.mydomain.com/*, but it has to match the subrequest URL, which in this case is https://something.com/someResource, which doesn't match. It doesn't matter that the original worker request matched -- what matters, in this case, is whether the subrequest URL matched.
Unfortunately, you cannot create a page rule that matches a domain other than your own.
Instead, what you'll need to do is reverse things. Set your SSL mode to "full" by default, but then use page rules to set it to "flexible" for your own domain.
(Note: The "SSL Handshake fail" error itself is actually a known bug in Workers, that happens when you try to talk to a host outside your zone using HTTPS but you have "flexbile" SSL set. We do not use flexible SSL when talking to domains other than your own, but there's a bug that causes the request to fail instead of just using full SSL as it should.)

Related

Haproxy as reverse proxy problem in ssl pathtrough

I setup haproxy as reverse proxy in our organization . we want when the client request for some web site like lenovo or oracle or etc. …the request must be passed through our reverse proxy server .(because our client set our dns server and i defined reverse proxy’s ip as those such domain in our dns server). i using SSL passthrough .but i have some problem in this case.
1- some time haproxy doesnt work fine and have problem to load right certificate.for example when i want to see www.amazon.com haproxy load wrong certificate(SSL_ERROR_BAD_CERT_DOMAIN) so firefox prevent to load website. in this case i have www.intel.com in haproxy config so haproxy getting confused and load www.amazon.com with intel certificate website.
2-I want all sub domain of website like *.oracle.com or *.lenovo.com passed through our reverse proxy so we don’t need to register sub domains of website one by one in haproxy server .
i try with -reg or matching pattern method but all of them need to final destination.
3- some time redirection cant work properly and we facing http to https redirection error .(some time client enter lenovo.com or intel.com (means http requesting).to over come this problem i defined http frontend and redirect all request to https except one hypothetical request by acl . but my issue some time appear.
This is simple done by req_ssl_sni and writing simple acl to forward request but attention to just write single forntend and backend ,because multi frontend and backend cause a confusing in haproxy.

Set mod_security to detectionOnly for a specific page?

If mod_security is set to ON for the whole website, is there a way I can set specific pages to detection_only?
Use case is that the application is used to configure websites, and use of CSS or js is very common, but very likely to make modsecurity throw an XSS rule exception. I'd like to detect those exceptions but not block them, on those pages only. However on all other pages I want rule exceptions to block.
More gritty detail: The application is actually an IIS application running on another Windows server, while mod_security is running in Apache on a linux server. haproxy directs incoming requests to apache, and apache takes the request through modsecurity; if it passes, it reverse-proxies it back to haproxy, which then passes it to IIS.
== incoming request ==> haproxy ==> apache
v
mod_security
v
IIS machine <== haproxy <== mod_proxy
(yes, there's a good reason for using haproxy. We have hundreds of https certificates, and we can point haproxy at a folder full of them and it will pick the right one, based on the SNI https request. Haven't found anything else that can do that yet.)
So there's no directory on the apache side where a .htaccess file would make sense, at least to my tiny mind.
Paths to be treated as DetectionOnly would match the host admin.mysite.com and the path ^/site/[a-zA-Z0-9-]+/Settings$
Something like this should work (untested):
SecRule REQUEST_HEADERS:Host "#streq admin.mysite.com" "phase:1,id:1234,chain"
SecRule REQUEST_URI "^/site/[a-zA-Z0-9-]+/Settings$" "ctl:ruleEngine=DetectionOnly"
Just add that rule before any of the others and make sure the id is unique (I've used 1234 as an example).
The rule engine will be reset for the next request as ctl changes are for this request only.

Connection Partially Encrypted in Firefox :SSL

I have uploaded my SSL certificates to IAM purchased from Comodo and evrything looks fine in chrome and opera. But mozilla is giving an error: "Connection Partially encrypted". I am not able gauge why this is happening.
Link : https://www.advisorcircuit.com/
Please tell me what is the possible culprit for this?
and also i want to know , how can i redirect my users to HTTPS ebven if they type http as even if i type http the website loads and opens.
I am using AWS t2.medium instance. So is there any configuration i need to do in my console??
Redirection:
You have a few options:
Block HTTP traffic, only allow HTTPS on the Security Group level ( Not the nicest solution.
Use an Elastic Load balancer, Listening only on HTTPS port. ( Same as above)
The webserver ( most of them like Tomcat, IIS, etc) supports a redirection, so it sends back "HTTP/1.1 301 Moved Permanently", then the client browser does the call again on HTTPS.
If you use Elastic Load Balancer with SSL termination ( which is a good practice, less load on your server, easier setup of the SSL Certificate). Then all your traffic inside your VPC goes on port 80. In this case you need to setup your webserver to redirect differently. Instead of the incoming port, the trigger for the redirection should be the based on the "X-Forwarded-Proto" header value, which is the original protocol what the client is using.
For production environment the last setup is an AWS Best practice. ( Of course there are also other solutions)
Your site is running Apache/2.2.29. You can redirect your virtual host traffic from 80->443 in Apache itself. That way if someone goes to http://www.yourdomain.com then get redirected to https://www.yourdomain.com
ServerFault has an post explaining how to use Apache mod_rewrite to accomplish this
https://serverfault.com/a/554183/280448
Also you need to adjust the SSL cipher suites that your site accepts. Your ELB has an option to change cipher suites and you can deselect some there. The two you definitely want deselected are RC4 and SSL3.
Here's the full report if you want to make more changes
https://www.ssllabs.com/ssltest/analyze.html?d=www.advisorcircuit.com&s=52.7.154.196&latest

Multiple sites per Apache server with SSL showing wrong site with HTTPS

I have a Debian server which is running a number of client sites. Most of these are not running SSL so accessing by HTTP is fine.
I have one customer with an SSL certificate and accessing their site via HTTPS is fine too.
The problem comes if you try to access one of the other sites with HTTPS you get directed to the other site that has the SSL certificate.
For instance, lets say we have the following sites on the server:
alpha.net
bravo.net
charlie.net (SSL)
delta.net
So as you can see, charlie is the only one with SSL, and irrespective of if you go to http charlie.net or https charlie.net, it works fine.
http to all the other sites is fine, but if you were to go to https alpha.net, it will initially come up with an Invalid Certificate error and let you continue but whilst it has alpha.net in the address bar, its actually showing the charlie.net site in the browser.
I have researched SNI and how if any other sites have SSL I'll need to put them all on specific IP addresses (something else I need to try to work out how to do as I have no idea) but I am not sure why this is happening or how I resolve it.
Has anyone else encountered this before and how did you get around it?
Many thanks,
Rob
This does not have anything to do with SNI, as you currently only have one HTTPS server. What happens, as you've stated in your comment, is that the alpha.net domain resolves to your server's IP. Your Apache server is set up to listen for requests on port 443 on this IP, and to serve the contents of charlie.net to these requests. (And the certificate error means that the browser noticed the discrepancy between the certificate's alleged domain name and the domain name used for the request.)
Redirecting from HTTPS to HTTP is probably more trouble that it's worth, since you would need valid certificates for each domain, lest you present your users with another security warning. This would entail creating virtual hosts for alpha.net:443 and so on, on an SNI capable server (i.e., later versions of Apache 2.2+ with openssl), and adding a redirection like so:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
Probably the easiest course for your problem is to use a different IP for charlie.net. With this setup, there would be no way for alpha.net (and so on) to display the contents of another site.
If you have multiple IPs on your server, use a unique one for the SSL site, all non-SSL sites share another IP.
Since SSL doesn't care what is the domain you are visiting, it only cares if the current domain is approved from the list of domains(Common Name) it gets from the Ip address.

How do I make apache SNI hosts without certificates redirect to http address?

I have an apache server with multiple named hosts all working fine for port 80 http traffic.
(A VPS with one unique IP address)
I have one domain that has a SSL certificate and that domain is configured to handle both http and https traffic.
However if someone accidentally adds https to the beginning of a none SSL configured URL I get a typical certificate warning error (expected) and then if the user accepts the error (depending on the browser) it displays the SSL site I have configured instead of the original non-ssl domain.
I've read up a bit about SNI, but I don't have certificates for each of the other domains and would rather the server either not respond to the SSL request on anything else but one specific domain or redirect to the http version of the site.
Suggestions please as to how I approach this.
Kind regards, Spencer
For security reasons, what you're trying to achieve cannot work.
The browser (which implements the mechanisms to check the certificate) cannot know whether the user typed https:// instead of http:// accidentally or intentionally. Since it's ultimately up to the users to check that https:// is used when they think it's required, browsers should simply perform the actions requested by the users.
A redirection from https:// to http:// should always start with a valid https:// connection. SNI won't help you much there if you can't have valid certificates for the initial connection.
Otherwise, it would be fair for browsers to assume there may be a MITM attack in progress. Typing in https:// explicitly (or using HSTS) is the only reliably mechanism against MITM tools like SSLstrip, which would otherwise be capable of downgrading (or preventing an upgrade from http:// to https://).