I'm new to rails. I want to create secure control.
here what I did :
I created a secure and change routes.rb as
scope :constraints => {:protocol => 'https'} do
get "secure/index"
end
but, I.m having this error
[2012-10-08 12:07:07] ERROR bad URI \x12p\x00\x00H\x00��'.
[2012-10-08 12:07:07] ERROR bad URIpqn���|�լ%[�y���\x00\x00H\x00��'.
when I request https://localhost:3000/secure
thanx..
i think that you have a misunderstanding of secure http communication!
http and https are two different things. thats why they usually work on two different ports! http is 80 and https is usually 443.
https needs a signed certificate and which is usually handled by your webserver (apache, nginx etc). it's also possible to handle the https stuff within rails and there are some nice gems to handle configuring ssl-enforcement.
have a look at this post to get started: http://www.simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/
Related
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.)
I inherited a weird situation from a client that I'm no expert at. This client has 3 domain names, the main one being, for example, domain-a.com. They also have domain-b.com and domain-c.com redirecting to domain-a.com. All domains live on the same server.
So the problem comes up because they had SSL certs on all 3 domains and the cert on domain-c.com expired and they need to get a new one. This had me thinking, do they even need certs on domain-b or domain-c if it just redirects? Also consider that the domain-c.com domain is the domain of their email, but as far as I know, the two don't affect each other.
TL;DR: Do you need SSL certs on redirects to a page with an SSL cert.
Yes.
The redirection is an HTTP-level action which happens inside the SSL envelope.
The client needs to establish an SSL connection to the original host before it 'sees' the redirect, then after completing the redirect it must establish another SSL connection to the target host.
So you definitely need an SSL certificate on redirects to a page with one.
If you have requests via TLS to domain-b & domain-c than yes, you need TLS support on them.
There's also a security related aspect in this. Plain text communication to domain-b.com & domain-c.com means a plain text redirect to domain-a.com. Because it redirects to SSL only the communication to domain-a.com is secured. This leaves the redirect from domain-b & domain-c vulnerable to a MITM attack. An attacker can intercept the requests and redirect the client to a different site under their control.
This is not easy to prevent, unless you have something like HTTP Strict Transport Security (HSTS, RFC) in place on all domains and the visitor visited the sites before or they're in preload list of their browser.
In any case, to make it more secure: Upgrade the client to TLS on their first request to any of the three domains, and redirect to https instead of http when going to domain-a from domain-b & domain-c. Use HSTS with preload and HTTP Public Key Pinning on all domains and you're good to go.
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
I have made reverse connection to one of web servers on which is SSL applied and the the content is in dir (http://webserver.com/directory) ,so i had to use rewrite rule and that works well.
The thing is that nginx can't pass SSL from backend webserver and i get error on silverlight application..
Could someone advise me on what to do ? Config is very basic as only rewrite is added additionally.
Looking forward for suggestions,ideas,answers.
Best regards.
Edit: pastebin.com/SnyHaUL4
As far as i know, you could say that "it's not a bug, it's a feature", one of the features of SSL that it prevents Man in the middle attacks, if you want to use SSL then nginx it self should have an SSL key and allow https connection, otherwise the user will see the well known yellow warning page about untrusted SSL,
If you implement the SSL for nginx, then the connection would be like this
client -> nginx ssl -> nginx -> server ssl -> server
The connection will be encrypted and decrypted twice on the way to the server, the client wont see the server SSL and will only see the nginx SSL.
If you don't have or don't want to use SSL on your nginx, then you need to make the connection to it unsecured, then the warning won't appear and every thing would work fine.
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://).