I have a rails app that is running on heroku and am using Cloudflare Pro with their Full SSL to encrypt traffic between: User <-SSL-> Cloudflare <-SSL-> Heroku, as detailed in: http://mikecoutermarsh.com/adding-ssl-to-heroku-with-cloudflare/ .
I am also using the rack-ssl-enforcer gem to force all http requests to go through https.
This is working properly, except I have the following issues, by browser:
1) Firefox. I have to add a security exception the first visit to the site, getting the "This site is not trusted" warning. Once on the site, I also have the warning in the address bar:
2) Chrome: page loads first time, but the lock in the address bar has a warning triangle on it, when clicked displays:
Your connection is encrypted with 128-bit encryption. However, this
page includes other resources which are not secure. These resources
can be viewed by others while in transit, and can be modified by an
attacker to change the look of the page. The connection uses TLS 1.2.
The connection is encrypted and authenticated using AES_128_GCM and
uses ECDHE_RSA as the key exchange mechanism.
Safari: initially loads with https badge, but it immediately drops off
Is there a way to leverage Cloudflare SSL + piggyback of Heroku native SSL without running into these security warnings? If not, I don't see much value in the configuration.
My apologies for slinging erroneous accusations against Cloudflare and Heroku :-)
Turns out the issue was not the fault of either, but instead that images on the app (being served from AWS S3) were being served up without https.
If anyone runs into this situation, lessons learned across a wasted day:
S3 only lets you serve up content via https if you serve from your bucket's dedicated url: s3.amazonaws.com/your-bucket-name/etc..
a) I tried setting the bucket up for static website hosting, so I could use the url "your-bucket-name.your-url.s3-website-us-east-1.amazonaws.com/etc...", and then set up a CNAME within my DNS that sends "your-bucket-name.your-url" to "your-bucket-name.your-url.s3-website-us-east-1.amazonaws.com/etc...", to pretty up urls
b) this works, but AWS only lets you serve via https with your full url (s3.amazonaws.com/your-bucket-name/etc..) or *.s3-website-us-east-1.amazonaws.com/etc...", which doesnt work if you have a dot in your bucket name (your-bucket-name.your-url), which was required for me to do the CNAME redirect
If you want to use AWS CDN with https, on your custom domain, AWS' only option is CloudFront with a SSL certificate, which they charge $600/mo, per region. No thanks!
In the end, I sucked it up and have ugly image URLs that looks like: https://s3-website-us-east-1.amazonaws.com/mybucketname...", and using paperclip, I specify https: with ":s3_protocol => :https," in my model. Other than that all is working properly now.
Related
I am using Automated Certificate Management that Heroku makes available for apps with paid dynos. my_app.herokuapp.com accurately reflects the SSL certificate and loads as a HTTPS:// page.
But my custom domain, www.my_app.com doesn't load as HTTPS://
My custom domain is from Google Domains and here is the CNAME mapping -
Custom Resource Records
www is mapped to www.my_app.com.herokudns.com.
Subdomain forward
my_app.com --> https://www.my_app.com
Any thoughts on where I could be going wrong? I can't seem to find step-by-step instruction anywhere, please point me to any resources you all found to be useful.
When I test my ASP.Net app locally, I use a DNS tool called DNSSpeeder which takes over the DNS process for my machine. In effect, I can setup www.mysite.com locally and enter an IP address like 192.168.178.200 and in my browser just enter www.mysite.com and it launches from my local IIS web server. When I'm ready for production, I just disable DNSSpeeder so that an Internet's DNS is used to lookup my site.
The problem I am facing is when I use Google OAuth to exchange my code for a token. It returns with an error of redirect_uri_mismatch. It isn't clear to me what is actually going out on the wire to Google's server and what URI Google is seeing. The URI redirect does match what is in the API console, although that doesn't say anything about what is actually sent to Google's server after it leaves DNSSpeeder. I tried Wireshark but it shows nothing. Probably encrypted with https. Instead of using http://localhost:8080, I tried http://localhost:80 as well as http://192.168.178.200 for the Javascript origins but that didn't help.
Is it possible to use an IP address other than localhost when testing locally to get a successful token?
"Is it possible to use an IP address other than localhost when testing locally to get a successful token?"
Yes it is possible. My setup is that I have configured two redirect URLs in the Cloud Console, (http://www.mydomain.com/redirect and http://dev.mydomain.com/redirect).
I then edit /etc/hosts (on linux, the Windose equivalent is under system32\drivers somewhere) to map dev.mydomain.com to 127.0.0.1.
And it works just fine. You may need to tweak your app so the redirect URL is not hardcoded, but is in fact varied based on whether your app senses it's in dev or production.
One thing to be aware of is that the confiured redirect URL must be a character for character match to the actual URL. So be careful that you have both http and https variants, and also watch for a trailing slash. If necessary configure both with and without the trailing slash.
Hi I have a website that I will be developing in the future.
Upon looking at the current website I noticed something weird that I have never seen before and also Google'd and found nothing.
If you go to: http://www.smartrainer.com.au you get the normal site
But, if you go to: https://www.smartrainer.com.au you get redirected to another website and are also given an SSL warning beforehand (in Chrome)
The site is hosted on a UNIX / PHP server and the .htaccess file currently has nothing that would suggest that it's redirecting to this other website.
Any help or insight would be appreciated with this, because I've never heard of this or seen this before.. The client also has no idea why it would be directing to that company that we've never heard of
Thanks!
It sounds like you're using a shared hosting server.
In plain HTTP, the server can know which host the client is requesting using the Host header in the request (this is based on the URL). Apache Httpd supports this with what it calls Name-based virtual hosts.
The HTTPS configuration is separate from the HTTP configuration in Apache Httpd (and presumably a number of other servers). Having virtual hosts (typically on a shared host) for the HTTP configuration doesn't mean that the same configuration is replicated for HTTPS.
HTTPS presents another problem: choosing which certificate to send before being able to see the Host header. Indeed, the server needs to send the client a certificate with the correct name during the SSL/TLS handshake, which happens before any HTTP traffic is sent (so before the Host header can be read). To overcome this problem, some hosts will set up a certificate valid for multiple host names (typically multiple Subject Alternative Names, or sometimes wilcards), others will use Server Name Indication (which isn't supported by all clients).
To get your server to host your site for HTTPS, you'd need:
To make sure the certificate it serves is valid for your host name (otherwise, there will be a warning message).
That the virtual hosts (or equivalent) it serves are configured for your host too.
In your case it seems that (a) your server is serving a single certificate that is not valid for your host and (b) your host isn't configured for HTTPS anyway, since you're falling back to what's probably the default host.
You may solve this issue by redirecting HTTPS URL to HTTP URL from your .htaccess. This error might because of shared hosting. If you cannot solve this issue from your .htaccess than you may also contact your hosting provider on this issue.
I have a Rails 4 app, deployed on Heroku. I want my app to be served via pure HTTP, not HTTPS. So I haven't done anything special to configure HTTPS redirect (at least I think so). But nevertheless,
my app got a redirect to https every time I visit it. It behaves the same way in both cases, via subdomain.herokuapp.com and via my-subdomain.mydomain.tld, e.g. prepends https:// to the address. Which in turn (naturally) causes browser warnings about security.
Can I disable such behaviour?
By the way, mydomain.tld and www.mydomain.tld both work without this strange redirection, as well as a dummy app generated just for this purpose.
It caused by config.force_ssl = true in production.rb
My ASP.NET MVC3 site, www.mysite.com, pulls images from images.mysite.com. When I'm not logged into my site and using SSL, it works flawlessly. However, when logged in, it get the
Only secure content is displayed.
message in IE9. I understand that. What's the best way to deal with switching URL's for my images? Should I check to see if I'm currently using SSL and point my images to https://images.mysite.com, otherwise http://images.mysite.com?
EDIT: This is an e-commerce site, so most of the time the site is browsed unsecured. But after login, I still need to pull some of those same images, and of course if they browse back to a regular catalog page, it would need to access images. Perhaps I will just have to always use https://images.mysite.com. Just seemed like overkill.
I believe the problem only happens when you're in a secure page accessing content over http. So, for pages that can be seen both in http or https, might be as easy as always using https to get the images, regardless if you're in http or https.
You will always get that message if you are pulling content from a non-SSL site when viewing over SSL. If you site is mostly SSL protected, just always pull images from https://images.mysite.com as you do not get the error if you pull SSL content into a non-SSL site.
Otherwise, you will need to know which pages are only viewable over SSL and which ones are not, and link appropriately.
Lastly, if you site is available over both, you will probably need to look at the HTTPS server variable to determine if you are on SSL or not and use this to determine your link (http or https).
Did you try prefixing with ~instead of ../ or /?
This worked for me.