Recently google announced all website must be HTTPS compliance. I want to know criteria of HTTPS compliance. One criteria is all contents loaded in the website must be loaded through HTTPS connection.
Question 1
What are the full criteria for HTTPS compliance ?
Question 2
If I have some http links in my website ( linktext ) is it HTTPS compliance or non compliance ?
My website supports HTTPS. But it also works for HTTP. For example
https://example.com and http://example.com both works. Then is it HTTPS compliance or non compliance.
My assumption is both cases are HTTPS compliance. Could someone clarify ?
You're likely referring to their Ad Network:
https://support.google.com/richmedia/answer/6015286?hl=en
This excludes the majority of websites need for SSL compliance. Typically SSL compliance is only required if you are handling personal data. But to answer your second set of questions:
Outbound links will not cause an issue with SSL compliance. The only time a URL is subject to those rules is when they are loading a server asset.
You can either set up a redirect in your .htaccess to redirect users to the secure version or set up a canonical URL so that the non secure version doesn't get indexed.
Related
I had the SSL installed on my site for a day and uninstalled it. Now in serps, google shows some of the pages in https version. I don't think this is a duplicate content issue because only one version of the web page shows up in serps. I'm not sure how to fix this because the mix of http hand https show up.
Why does google randomly show https version of my pages?
How can i tell google to use the http version of those random pages?
Thanks in advance!
I think more information is needed to fully answer this question, however, most likely Google is showing the HTTPS version of your page because your site was using HTTPs at the time when Google visited and indexed your page, thus the HTTPS version was cached.
You can partially manage your search page and request that Google re-index your site from Google Web Developer tools. https://www.google.com/webmasters/tools/. However, the change isn't guaranteed and won't take place immediately.
Furthermore, you can control whether a visitor uses HTTPS or HTTP when visiting your site via standard redirects. In other words, update your webserver or web application so if someone visits http://mysite they will be redirected (preferably with a 301 status code for SEO reasons) to https://mysite.
Finally, as a general practice, you should really use HTTPS as browsers may highlight warnings for non-secured traffic in the future. For sites I manage, "http" requests are automatically redirected to the "https" of the same URL to ensure all traffic is always over a secure connection.
Is there a way on a Google Search Appliance to enable optional https?
Under settings, under the heading Force secure connections when serving the options are:
No.
Use HTTPS when serving secure results, but not when serving public results.
Use HTTPS when serving both public and secure results.
I don't want to Force secure connections though, I want them to be optional.
ie, if someone requests the site as HTTP it serves as HTTP and if they request it as HTTPS it serves as HTTPS.
If I choose the 1st or 2nd options it accepts connections on HTTPS but immediately redirects to HTTP (ie, it forces HTTP). And the 3rd option forces HTTPS.
Is there any other settings that would enable it to accept HTTPS optionally?
You must install a valid ssl certificate or create a self-signed certificate. (Administration->SSL Settings)
In SSL Settings->Other Settings->"Force secure connections when serving?" you must select either: 'a' or 'b'
a. "Use HTTPS when serving secure results, but not when serving public
results."
b. "Use HTTPS when serving both public and secure results."
Unless all requests are coming from https, chances are you will select 'a'.
If 'b' is selected, you will receive an "unknown error" if sending query over standard http.
Now here's the major caveat:
Your observation that https still redirects to http, even with 'a' selected, is correct. The only method that I am aware of to force SSL when serving results with option 'a' is to send the additional 'access' query parameter '&access=a'
'a'=all
'p'=public (default)
https://www.google.com/support/enterprise/static/gsa/docs/admin/72/gsa_doc_set/xml_reference/request_format.html#1087053
BEWARNED: Depending on how your GSA is configured, there may be privacy implications if your organization maintains public collections containing private urls requiring authentication. URLS that require auth will be served right along with the rest of your results.
Changing the settings you mention to "No" will cause the GSA to use whatever protocol you started the experience with to be used.
Choosing the other options will cause the GSA to switch protocols.
Edit - It looks like this not possible. It doesn't matter what you request, the GSA will redirect based on the config.
If you create an SSL certificate for your GSA's host name and install the valid SSL certificate then it should serve results on port 443 (HTTPS) correctly.
i.e. if your GSA is "search.mydomain.com" then create a properly signed SSL certificate in that name and install to the GSA.
Typically this works without a certificate but the browser will show a warning message due to no SSL certificate / invalid SSL certificate.
I read if the request is authenticated or secure, it won't be cached. We previously worked on our cache and now planning to purchase a SSL certificate.
If caching cannot be done with SSL connection then is that mean our work on caching is useless?
Reference: http://www.mnot.net/cache_docs/
Your reference is wrong. Content sent over https will be cached in modern browsers, but they obviously cannot be cached in intermediate proxies. See http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/ or https://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/ for example.
You can use the Cache-Control: public header to allow a representation served over HTTPS to be cached.
While the document you refer to says "If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.", it's within a paragraph starting with "Generally speaking, these are the most common rules that are followed [...]".
The same document goes into more details after this:
Useful Cache-Control response headers include:
public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically private.
(What applies to HTTP with authentication also applies to HTTPS.)
Obviously, documents that actually contain sensitive information only aimed for the authenticated user should not be served with this header, since they really shouldn't be cached. However, using this header for items that are suitable for caching (e.g. common images and scripts) should improve the performance of your website (as expected for caching over plain HTTP).
What will never happen with HTTPS is the caching of resources by intermediate proxy servers (between the client and your web-server, at least the external part, if you have a load-balancer or similar). Some CDNs will serve content over HTTPS (assuming it's suitable for your system to trust these CDNs). In general, these proxy servers wouldn't fall under the control of your cache design anyway.
I'm developing on Heroku a site with a couple of subdomains. One of them is signup (as in signup.myapp.com) which requires SSL access -- of course! But the rest of the subdomains, such as www, do not require https to access.
The problem is that the client only purchased an SSL certification for signup.myapp.com. This means that, when a user tries to access other places of my site with https (such as https://www.myapp.com), SSL certification does not validate and browsers tell the user that the site could be malicious... not good for branding.
I tried to make the site redirect from https to http, but of course this failed, because SSL was checked before the redirect could be sent.
Is there a way that I can deny access to these places of my site from https, so that users encounter, for instance, a 404 page instead? Or, do you know of any other ways to handle this situation? (the client is reticent to acquire a new SSL certificate, specially a wildcard certificate).
Unfortunately, you need a certificate for each of the domains (or a wildcard one as you mention), see e.g.:
How to redirect https to http without any SSL Certificate
The problem is that certificate is the first thing checked, way before anything else happens. If that fails, browser will typically display "get me out of here!"-kind of notification. There's no built in support for SSL-to-non-SSL transition.
You can shut down https://www.example.com (i.e. make your Web server not listen on port 443), but that of course won't yield a 404, also bad for branding.
With just one non-wildcard certificate, the only thing you can do is put all the pages under that domain. I.e. instead of https://signup.example.com/a/b/c, you need to do https://www.example.com/signup/a/b/c or something along those lines.
On the other hand, you can buy the certificate for under $100/year (or $150 total for 2 years) at GoDaddy:
http://www.godaddy.com/ssl/ssl-certificates.aspx
so, depending on your context, it might just pay off to pay this instead of doing any additional development.
How secure would this setup be ?
Unsecure page 'http://www.site.com' makes an XMLHttpRequest with POST
to url 'https://www.site.com/dosomething.asp'
The page dosomething.asp has header 'Access-Control-Allow-Origin: http://www.site.com' set
and returns some user related data that needs to be secure.
No errors, all goes well.
How secure is the actual POST request ?
How secure is the responseText from this request ?
The most significant issue I can see is that your unsecure page is not secure (ok, obvious). If someone were to attempt a man-in-the-middle attack on that unsecure page, they could edit the functionality of the page (using JavaScript injection, etc.) to intercept the content being sent to and received from the secure URL. You are best off to use both pages in secure mode (SSL/TLS).
As soon as you introduce a non-SSL component to your application, you have lost all the benefits of SSL. You are only as secure as the weakest part. This is why browsers report mixed SSL/non-SSL content as a security alert to the user.
Wireshark is a program that monitors network packets traveling across a network. It's free and popular. The definitive way to answer this question would be get Wireshark, take a day to learn it, and apply it.
The filter to see traffic from the source site would be:
(ip.src == [ip address of source]) && (ip.dst == [ip address of target])
Swap ip.src and ip.dst to see what's coming back. You could actually combine both in one filter expression actually.
This would work provided that you're on the network through which the packets are traveling.
One final item: Here's a description of PKI (https/SSL/TLS): http://www.mitre.org/news/the_edge/february_01/steve.html
I Wiresharked a sort of similar situation, and verified I was sending and receiving TLS (https) traffic. But it wasn't this situation exactly so I don't want to speculate.