Results for suche.org

Check again2017-07-22 04:47:15 Etc/UTC

Input URL: http://suche.org/

Final URL: https://suche.org/

Secure connection

suche.org uses HTTPS by default.

HTTPS encrypts nearly all information sent between a client and a web service. Properly configured, it guarantees three things:

  • Confidentiality. The visitor's connection is encrypted, obscuring URLs, cookies, and other sensitive metadata.
  • Authenticity. The visitor is talking to the "real" website, and not to an impersonator or through a "man-in-the-middle".
  • Integrity. The data sent between the visitor and the website has not been tampered with or modified.

A plain HTTP connection can be easily monitored, modified, and impersonated. Every unencrypted HTTP request reveals information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace.

The goal of the Internet community is to establish encryption as the norm, and to phase out unencrypted connections. See W3C, IETF, IAB. Also:

  • Browsers support HTTP/2 — which improves page loading speeds — only over encrypted connections.
  • Google Chrome (1, 2) and Mozilla Firefox (1) will mark plain HTTP as affirmatively non-secure and make powerful features impossible to use on non-secure sites.
  • Google has begun to favor HTTPS websites in search rankings.

Please note that this tool only checks whether HTTPS is used by default. Next step is to ensure that the server is configured correctly and not susceptible to attacks due to out-of-date software, weak ciphers, etc.

Such things are out of scope for this tool, but Qualys SSL Labs provides an excellent free service that lets you check how a server is doing:

Analyze suche.org on SSL Labs

Strict Transport Security enabled

HSTS enabled with value max-age=31536000; includeSubdomains; preload.

HTTP Strict Transport Security (HSTS) is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.

When a browser knows that a domain has enabled HSTS, it does two things:

  • Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.
  • Removes the ability for users to click through warnings about invalid certificates.

Strict Transport Security was proposed in 2009, motivated by Moxie Marlinspike's demonstration of how a hostile network could downgrade visitor connections and exploit insecure redirects. It was quickly adopted by several major web browsers, and finalized as RFC 6797 in 2012.

The basic problem that HSTS solves is that even after a website turns on HTTPS, visitors may still end up trying to connect over plain HTTP. For example:

  • When a user types "example.com" into the URL bar, browsers default to using http://.
  • A user may click on an old link that mistakenly uses an http:// URL.
  • A user’s network may be hostile and actively rewrite https:// links to http://.

In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds (the policy is refreshed every time browser sees the header again):

Strict-Transport-Security: max-age=31536000;

In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be "preloaded" into browsers:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Since it's just an HTTP header, HSTS is very easy to add to a domain.

However, to enable HSTS for a domain via the HTTP header, the browser does have to see the header at least once. This means that users are not protected until after their first successful secure connection to a given domain.

To solve the "first visit" problem, the Chrome security team created an "HSTS preload list": a list of domains baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit. Firefox, Safari, and newer versions of Internet Explorer also incorporate Chrome’s HSTS preload list.

The Chrome security team allows anyone to submit their domain to the list, provided it meets a few requirements.

Read more about HSTS and how to configure it in nginx, Apache and IIS.

Referrers are (probably) leaked

When you click a link, your browser will typically send the HTTP referer [sic] header to the webserver where the destination webpage is at. The header contains the full URL of the page you came from. This lets sites see where traffic comes from. The header is also sent when external resources (such as images, fonts, JS and CSS) are loaded.

The referrer header is privacy nightmare as it allows websites and services to track you across the web and learn about your browsing habits (and thus possibly private, sensitive information), particularly when combined with cookies.

Let's say you're logged in on Facebook. You visit a page with the URL http://www.some-hospital.com/some-medical-condition. On that page, you click a link to their Facebook page. Your browser then sends Referer: http://www.some-hospital.com/some-medical-condition to facebook.com, along with your Facebook cookies, allowing Facebook to associate your identity with that particular page.

The problem is made worse by the fact that many websites load resources like images and scripts from dozens of third-parties, sending referrer information to all of them, with the typical visitor having no idea that this is happening.

Thanks to a fairly recent development, Referrer Policy, it's finally possible for websites to tell browsers to not leak referrers. It lets you specify a policy that's applied to all links clicked, as well as all other requests generated by the page (images, JS, etc.).

A few different policies are offered, such as origin (strips everything except the origin) and origin-when-cross-origin (sends full URL with same-origin requests, otherwise stripped). The only one we recommend is no-referrer, which kills the referrer header entirely for all requests, no matter the destination.

A referrer policy can easily be set with a <meta> element in your HTML. Simply include this inside the <head> section:

<meta name="referrer" content="no-referrer">

While still a work in progress, Referrer Policy is now supported by all major browsers (except Internet Explorer, although it is supported by Edge, the new browser in Windows 10).

First-party cookies

2 first-party cookies.

DomainNameValueExpires on
suche.orgsidxC7GBvwlQ11TcW6I03a0...session
.suche.orgEtagwyFGjfuyQ8LTwG4L0Cm0...2037-07-17 04:47:04Z

Third-party cookies

No third-party cookies without consent.

Third-party requests

No third-party requests.

A third-party request is a request to a domain that's not suche.org or one of its subdomains.

Content-Security-Policy enabled

Content-Security-Policy HTTP header is set to upgrade-insecure-requests; default-src 'none'; frame-ancestors 'none'; style-src 'self'; script-src 'self'; img-src 'self'; font-src 'self'; media-src 'self'; report-uri https://suche.org/csp.report.

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. It can also help prevent information leakage.

report-uri.io has excellent (free) tools with which you can build or analyze a Content Security Policy.

HTTP headers

Header
Set?
Public-Key-Pins
YES, pin-sha256="I3dI5BuM4PHlzYhqmtMf4OUPahIOIqIzP4rxjEFd3X0="; pin-sha256="d7TeQjbH3bijsmFiyt72NNAfh2zF05EMk4MQkailomI="; pin-sha256="KeOxV4RKF6zabzykLPfZ74Kuak7QcUHyhlA3xGPmVqI="; pin-sha256="d7TeQjbH3bijsmFiyt72NNAfh2zF05EMk4MQkailomI="; pin-sha256="ffRIWsigiR307Kc+GxWXqGZDl8N2YfV0tieRocJEIVc="; max-age=31536000; report-uri="http://130.117.188.81/hpkp-report"

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.

Strict-Transport-Security
YES, max-age=31536000; includeSubdomains; preload

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS.

X-Content-Type-Options
YES, nosniff

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. This helps to reduce the danger of drive-by downloads. The only valid value for this header is "X-Content-Type-Options: nosniff".

X-Frame-Options
YES, DENY

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking.

X-Xss-Protection
YES, 1; mode=block

X-XSS-Protection sets the configuration for the cross-site scripting filters built into most browsers. The best configuration is "X-XSS-Protection: 1; mode=block".

What this tool checks (and doesn't check)

This tool attempts to simulate what happens when a user visits a specified page with a typical browser. The browser has no addons/extensions installed, and Do Not Track (DNT) is not enabled, since this is the default setting in most browsers.

External files such as images, scripts and CSS are loaded, but the tool performs no interactions with the page — no links are clicked, no forms are submitted.

Disclaimer: The results presented here might not be 100% correct. Bugs happen. This tool is meant to be used by site owners as a starting point for improvements, not as a rigorous analysis.

The HTTP header descriptions are based on the ones from securityheaders.io by Scott Helme, CC-BY-SA 4.0. Text about HTTPS partly adapted from the CIO Council's The HTTPS-Only Standard (public domain). MaxMind's GeoLite2 country database (CC-BY-SA 4.0) is used for GeoIP lookups.