Web Security Overview
Supported and well configured
HTTPS

Web sites need to use encryption to help their visitors know they're in the right place, as well as provide confidentiality and content integrity. Sites that don't support HTTPS may expose sensitive data and have their pages modified and subverted.

For all sites VERY IMPORTANT medium EFFORT
Supported and well configured
HTTPS Redirection

To deploy HTTPS properly, web sites must redirect all unsafe (plaintext) traffic to the encrypted variant. This approach ensures that no sensitive data is exposed and that further security technologies can be activated.

For all sites VERY IMPORTANT low EFFORT
Supported and well configured
HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an HTTPS extension that instructs browsers to remember sites that use encryption and enforce strict security requirements. Without HSTS, active network attacks are easy to carry out.

For important sites VERY IMPORTANT medium EFFORT
Supported and well configured
HSTS Preloaded

HSTS Preloading is informing browsers in advance about a site's use of HSTS, which means that strict security can be enforced even on the first visit. This approach provides best HTTPS security available today.

For important sites VERY IMPORTANT medium EFFORT
Supported and well configured
Content Security Policy

Content Security Policy (CSP) is an additional security layer that enables web sites to control browser behavior, creating a safety net that can counter attacks such as cross-site scripting.

For important sites IMPORTANT high EFFORT
Email Security Overview
Supported and well configured
STARTTLS

All hosts that receive email need encryption to ensure confidentiality of email messages. Email servers thus need to support STARTTLS, as well as provide decent TLS configuration and correct certificates.

For all sites VERY IMPORTANT low EFFORT
Supported and well configured
SPF

Sender Policy Framework (SPF) enables organizations to designate servers that are allowed to send email messages on their behalf. With SPF in place, spam is easier to identify.

For important sites IMPORTANT low EFFORT
Supported and well configured
DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism that allows organizations to specify how unauthenticated email (identified using SPF and DKIM) should be handled.

For important sites IMPORTANT low EFFORT

Name Server Configuration

Correctly functioning name servers are necessary to hold and distribute information that's necessary for your domain name to operate correctly. Examples include converting names to IP addresses, determining where email should go, and so on. More recently, the DNS is being used to communicate email and other security policies.

Test passed
Everything seems to be well configured. Well done.

DNS Configuration

These are the results of individual DNS queries against your nameserver for each resource record type.

Name TTL Type Data
terrax.net.     900 A 94.130.231.169            
terrax.net.     900 AAAA 2a01:4f8:c0c:4f2e:0:0:0:2            
terrax.net.     900 CAA 0 issue "letsencrypt.org; validationmethods=dns-01"            
terrax.net.     86400 CAA 128 iodef "mailto:caa@terrax.net"            
terrax.net.     900 MX 5 mx.h.terrax.net.            
_dmarc.terrax.net.     86400 TXT v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:postmaster@terrax.net; ruf=mailto:postmaster@terrax.net; rf=afrf; pct=100; ri=86400            
terrax.net.     86397 NS ns1.terrax.net.            
terrax.net.     86397 NS ns2.terrax.net.            
terrax.net.     86400 SOA ns1.terrax.net. hostmaster.terrax.net. 2018100502 28800 7200 604800 86400            
www.terrax.net.     900 A 94.130.231.169            
www.terrax.net.     900 AAAA 2a01:4f8:c0c:4f2e:0:0:0:2            
www.terrax.net.     86400 CAA 128 iodef "mailto:caa@terrax.net"            
www.terrax.net.     900 CAA 0 issue "letsencrypt.org; validationmethods=dns-01"            
www.terrax.net.     86400 MX 0 .            

DNSSEC

DNSSEC is an extension of the DNS protocol that provides cryptographic assurance of the authenticity and integrity of responses; it's intended as a defense against network attackers who are able to manipulate DNS to redirect their victims to servers of their choice. DNSSEC is controversial, with the industry split largely between those who think it's essential and those who believe that it's problematic and unnecessary.

Test passed
Everything seems to be well configured. Well done.

Analysis

Good
DNSSEC is well configured
Good. This domain name has well-configured DNSSEC.

Useful DNSSEC Tools

Certification Authority Authorization

CAA (RFC 6844) is a new standard that allows domain name owners to restrict which CAs are allowed to issue certificates for their domains. This can help to reduce the chance of misissuance, either accidentally or maliciously. In September 2017, CAA became mandatory for CAs to implement.

Test passed
Everything seems to be well configured. Well done.

CAA Policy Information

The DNS hostname where this policy is located.Policy host terrax.net
The issue property tag is used to request that certificate
issuers perform CAA issue restriction processing for the domain
and to grant authorization to specific certificate issuers.
issue
letsencrypt.org; validationmethods=dns-01  flags: 0
The iodef property specifies a means of reporting certificate
issue requests or cases of certificate issue for the corresponding
domain that violate the security policy of the issuer or the domain
name holder.
iodef
mailto:caa@terrax.net  flags: 128 ; critical

Analysis

Good
CAA policy found
Good. This domain name uses CAA to restrict which CAs are allowed to issue certificates for it.
Good
Policy uses reporting
Great. This policy uses reporting, which means that your contact information is available should someone need to contact you about a CAA violation. Do note that you're not guaranteed to be notified, given that CAs generally don't support notifications yet.

Email (SMTP)

An internet hostname can be served by zero or more mail servers, as specified by MX (mail exchange) DNS resource records. Each server can further resolve to multiple IP addresses, for example to handle IPv4 and IPv6 clients. Thus, in practice, hosts that wish to receive email reliably are supported by many endpoint.

Test passed
Everything seems to be well configured. Well done.
Server Preference Operational STARTTLS TLS PKI DNSSEC DANE
mx.h.terrax.net
2a01:4f8:c0c:4f2e:0:0:0:2
PTR: mx.h.terrax.net
5
< 220 mx.h.terrax.net ESMTP Postfix
> EHLO outbound.hardenize.com
< 250-mx.h.terrax.net
< 250-PIPELINING
< 250-SIZE 81920000
< 250-ETRN
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250-DSN
< 250 SMTPUTF8
> QUIT
< 221 2.0.0 Bye
Supports STARTTLS.
mx.h.terrax.net
94.130.231.169
PTR: mx.h.terrax.net
5
< 220 mx.h.terrax.net ESMTP Postfix
> EHLO outbound.hardenize.com
< 250-mx.h.terrax.net
< 250-PIPELINING
< 250-SIZE 81920000
< 250-ETRN
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250-DSN
< 250 SMTPUTF8
> QUIT
< 221 2.0.0 Bye
Supports STARTTLS.

Email TLS (SMTP)

Transport Layer Security (TLS) is the most widely used encryption protocol on the Internet. In combination with valid certificates, servers can establish trusted communication channels even with users who have never visited them before. Network attackers can't uncover what is being communicated, even when they can see all the traffic.

Test passed
Everything seems to be well configured. Well done.

TLS Configuration: mx.h.terrax.net (2a01:4f8:c0c:4f2e:0:0:0:2)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Server preference
Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca8
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc030
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Suite ID: 0xc028
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 256 bits (ECDHE 384 bits)

Analysis

Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Server enforces cipher suite preferences
Excellent. This server enforces server cipher suite preference, which means that it is able to select the best suite from the options submitted by clients. Combined with a well designed list of supported cipher suites, this settings enables negotiation of best security.
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Server prefers forward secrecy and authenticated encryption suites
Excellent. Not only does this server enforce its server preference, but it also has at the top of the list suites that support both forward secrecy and authenticated encryption. This is the best TLS 1.2 can offer.
Notice
Relaxed TLS assessment criteria applied to SMTP on port 25
We apply relaxed assessment criteria when evaluating TLS configuration of SMTP servers on port 25. This is because most delivery agents fall back to delivering via plaintext on failure to negotiate encryption. Some configuration elements that can be abused to attack other ports and protocols (e.g., SSLv2 and export cipher suites) are penalized in the same way as for other protocols. We will review this policy in the future.

TLS Configuration: mx.h.terrax.net (94.130.231.169)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
TLS v1.0
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Server preference
Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca8
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc030
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Suite ID: 0xc028
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Suite ID: 0xc014
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 256 bits (ECDHE 384 bits)
Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Suite ID: 0x39
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: DHE_RSA
Key exchange strength: 4096 bits
Forward secrecy: Yes
PRF: SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 256 bits (DHE 4096 bits)
Shows cipher suite configuration for this protocol version.TLS v1.0
Server preference
Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Suite ID: 0xc014
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: ECDHE_RSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 256 bits (ECDHE 384 bits)
Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Suite ID: 0x39
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: CBC
Key exchange: DHE_RSA
Key exchange strength: 4096 bits
Forward secrecy: Yes
PRF: SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 256 bits (DHE 4096 bits)

Analysis

Notice
Deprecated TLS 1.0 protocol supported
TLS 1.0 is a weak older protocol that should be phased out. Sites that aim at a wide audience might still need to support TLS 1.0 for the time being, because many older clients don't support newer protocol versions. Sites with a modern user base might be able to disable TLS 1.0 even now. We recommend that you enable logging of encryption parameters, after which you can examine your protocol usage and make decisions with confidence.
Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Server enforces cipher suite preferences
Excellent. This server enforces server cipher suite preference, which means that it is able to select the best suite from the options submitted by clients. Combined with a well designed list of supported cipher suites, this settings enables negotiation of best security.
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Server prefers forward secrecy and authenticated encryption suites
Excellent. Not only does this server enforce its server preference, but it also has at the top of the list suites that support both forward secrecy and authenticated encryption. This is the best TLS 1.2 can offer.
Notice
Relaxed TLS assessment criteria applied to SMTP on port 25
We apply relaxed assessment criteria when evaluating TLS configuration of SMTP servers on port 25. This is because most delivery agents fall back to delivering via plaintext on failure to negotiate encryption. Some configuration elements that can be abused to attack other ports and protocols (e.g., SSLv2 and export cipher suites) are penalized in the same way as for other protocols. We will review this policy in the future.

Email Certificates (SMTP)

A certificate is a digital document that contains a public key, some information about the entity associated with it, and a digital signature from the certificate issuer. It’s a mechanism that enables us to exchange, store, and use public keys. Being able to reliably verify the identity of a remote server is crucial in order to achieve secure encrypted communication.

Test passed
Everything seems to be well configured. Well done.

Certificate #1

Leaf certificate mx.h.terrax.net
Issuer: Let's Encrypt
Not Before: 09 Oct 2018 21:09:09 UTC
Not After: 07 Jan 2019 21:09:09 UTC (2 months 19 days)
Key: RSA 4096 bits
Signature: SHA256withRSA
 View details

Analysis

Good
Strong private key
Good. The private key associated with this certificate is secure.
Good
Strong signature algorithm
Good. This certificate uses a strong signature algorithm.
Good
Certificate matches hostname
Good. The provided certificate matches the expected hostnames.
Good
Certificate dates match
Good. The certificate is valid for use at this point of time.
Good
Certificate satisfies Chrome's CT requirements
This certificate contains embedded CT signatures and satisfies Chrome's CT requirements at this time.
Powerup!
Certificate doesn't require OCSP stapling
This certificate doesn't require OCSP stapling. If enabled, this feature increases the probability that a certificate will be considered revoked. This is a fairly new feature that is not yet very widely supported by various TLS clients. More information is available in RFC 7633.

Certificate Chain

Leaf certificate
mx.h.terrax.net | 664b108
Not After: 07 Jan 2019 21:09:09 UTC (2 months 19 days)
Authentication: RSA 4096 bits (SHA256withRSA)
 View details
Intermediate certificate
Let's Encrypt Authority X3 | 25847d6
Not After: 17 Mar 2021 16:40:46 UTC (2 years 4 months)
Authentication: RSA 2048 bits (SHA256withRSA)
 View details
Root certificate
DST Root CA X3 | 0687260
Not After: 30 Sep 2021 14:01:15 UTC (2 years 11 months)
Authentication: RSA 2048 bits (SHA1withRSA)
 View details

Analysis

Good
Certificate chain is correct
Good. This chain contains all the right certificates and in the right order.

Email DANE (SMTP)

DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone.

Test passed
Everything seems to be well configured. Well done.

DANE: mx.h.terrax.net (2a01:4f8:c0c:4f2e:0:0:0:2)

Specifies which certificate in the chain
is being pinned and how validation should
be performed.
Certificate Usage
Domain-issued certificate / DANE-EE (3) Creates a leaf pin for a certificate that must be
present in the certificate chain. PKIX validation is
not performed and the pinned certificate is assumed
to be trusted.
Determines if the association is made with
a certificate or with a public key (via
its SPKI structure).
Selector
SPKI structure (1)
Determines how matching is done; directly or via a hash. Matching Type SHA2-512 (2)
Contains the data necessary to perform the matching. Data c02a00f3c32cb9f960c35d698bfe89dafc2ae3e0400487bdf19f154dbada6a3bb2e1613004e42531d578229ff2594f20590b7904b30851a02fa080623190f6d6

Leaf certificate: RSA 4096 bits
Subject: CN=mx.h.terrax.net
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
mx.h.terrax.net (RSA 4096 bits)

Analysis

Good
Valid DANE configuration
Excellent. Your DANE configuration matches the certificate chain(s) provided by the service. Your TLS configuration enjoys the additional benefit of DANE validation.

DANE: mx.h.terrax.net (94.130.231.169)

Specifies which certificate in the chain
is being pinned and how validation should
be performed.
Certificate Usage
Domain-issued certificate / DANE-EE (3) Creates a leaf pin for a certificate that must be
present in the certificate chain. PKIX validation is
not performed and the pinned certificate is assumed
to be trusted.
Determines if the association is made with
a certificate or with a public key (via
its SPKI structure).
Selector
SPKI structure (1)
Determines how matching is done; directly or via a hash. Matching Type SHA2-512 (2)
Contains the data necessary to perform the matching. Data c02a00f3c32cb9f960c35d698bfe89dafc2ae3e0400487bdf19f154dbada6a3bb2e1613004e42531d578229ff2594f20590b7904b30851a02fa080623190f6d6

Leaf certificate: RSA 4096 bits
Subject: CN=mx.h.terrax.net
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
mx.h.terrax.net (RSA 4096 bits)

Analysis

Good
Valid DANE configuration
Excellent. Your DANE configuration matches the certificate chain(s) provided by the service. Your TLS configuration enjoys the additional benefit of DANE validation.

SPF

Sender Policy Framework (SPF) is a protocol that allows domain name owners to control which internet hosts are allowed to send email on their behalf. This simple mechanism can be used to reduce the effect of email spoofing and cut down on spam.

Test passed
Everything seems to be well configured. Well done.

SPF Policy Information Main policy

Host where this policy is located.Location terrax.net
SPF version used by this policy.v spf1
This mechanism matches if the sending IP address
is one of the MX hosts for the domain name.
mx
This policy element always matches. It's normally used
at the end of a policy to specify the handling of hosts
that don't match earlier mechanisms.
-all

Analysis

Info
SPF policy found

Policy text: v=spf1 mx -all

Location: terrax.net

Good
SPF policy is valid
Good. Your SPF policy is valid.
Good
Policy DNS lookups under limit
Good. Your policy stays under the limit of up to 10 DNS queries. The SPF specification Section 4.6.4. requires implementations to limit the total number of DNS queries. Policies that exceed the limit should not be used and may not work in practice.

Lookups: 1

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Test passed
Everything seems to be well configured. Well done.

DMARC Policy Information

The location from which we obtained this policy.Policy location _dmarc.terrax.net
DMARC version used by this policy.v DMARC1
Indicates the policy to be enacted by the receiver at
the request of the domain owner. Possible values are:
none, quarantine, and reject.
p
reject
Requested mail receiver policy for all subdomains.
Same format as for the p tag.
sp
reject
Indicates whether strict or relaxed DKIM
alignment mode is required.
adkim
s
Indicates whether strict or relaxed SPF
alignment mode is required.
aspf
s
Addresses to which aggregate feedback is to be sent.rua mailto:postmaster@terrax.net
Addresses to which message-specific failure
information is to be reported.
ruf
mailto:postmaster@terrax.net
Specifies the format to be used when reporting failures.rf afrf
Percentage of messages from mail stream to
which the DMARC policy is to be applied.
pct
100
Interval between aggregate reports. Defaults to 86400.ri 86400

Analysis

Info
DMARC policy found

Policy: v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:postmaster@terrax.net; ruf=mailto:postmaster@terrax.net; rf=afrf; pct=100; ri=86400

Host: _dmarc.terrax.net

Good
Policy is valid
Good. You have a valid DMARC policy.

MTA Strict Transport Security

SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

Feature not implemented or disabled
Your server doesn't support this feature.

HTTP (80)

To observe your HTTP implementation, we submit a request to the homepage of your site on port 80, follow all redirections (even when they take us to other domain names), and record the returned HTTP headers.

Test passed
Everything seems to be well configured. Well done.

URL: http://terrax.net

1
http://terrax.net
HTTP/1.1 301 Moved Permanently
2
https://terrax.net/
HTTP/1.1 307 Temporary Redirect
3
https://wiki.terrax.net/
HTTP/1.1 301 Moved Permanently
4
https://wiki.terrax.net/wiki/Hauptseite
HTTP/1.1 200 OK

Analysis

Warning
Same-host permanent redirection
This is a little-bit unusual. There's a permanent redirection from a root to a specific path on the same site. This may cause problems if the subpath ever changes. A temporary redirection is more appropriate in this case.

From: https://wiki.terrax.net/

To: https://wiki.terrax.net/wiki/Hauptseite

Good
HTTP server redirects to HTTPS
Good. This plaintext HTTP server redirects to HTTPS.

URL: http://www.terrax.net

1
http://www.terrax.net
HTTP/1.1 301 Moved Permanently
2
https://www.terrax.net/
HTTP/1.1 301 Moved Permanently
3
https://terrax.net/
HTTP/1.1 307 Temporary Redirect
4
https://wiki.terrax.net/
HTTP/1.1 301 Moved Permanently
5
https://wiki.terrax.net/wiki/Hauptseite
HTTP/1.1 200 OK

Analysis

Warning
Same-host permanent redirection
This is a little-bit unusual. There's a permanent redirection from a root to a specific path on the same site. This may cause problems if the subpath ever changes. A temporary redirection is more appropriate in this case.

From: https://wiki.terrax.net/

To: https://wiki.terrax.net/wiki/Hauptseite

Good
HTTP server redirects to HTTPS
Good. This plaintext HTTP server redirects to HTTPS.

HTTP (443)

To observe your HTTPS implementation, we submit a request to the homepage of your site on port 443, follow all redirections (even when they take us to other domain names), and record the returned HTTP headers. We use the most recent set of headers returned from the tested hostname for further tests such as HSTS and HPKP.

Test passed
Everything seems to be well configured. Well done.

URL: https://terrax.net

1
https://terrax.net
HTTP/1.1 307 Temporary Redirect
2
https://wiki.terrax.net/
HTTP/1.1 301 Moved Permanently
3
https://wiki.terrax.net/wiki/Hauptseite
HTTP/1.1 200 OK

Analysis

Warning
Same-host permanent redirection
This is a little-bit unusual. There's a permanent redirection from a root to a specific path on the same site. This may cause problems if the subpath ever changes. A temporary redirection is more appropriate in this case.

From: https://wiki.terrax.net/

To: https://wiki.terrax.net/wiki/Hauptseite

URL: https://www.terrax.net

1
https://www.terrax.net
HTTP/1.1 301 Moved Permanently
2
https://terrax.net/
HTTP/1.1 307 Temporary Redirect
3
https://wiki.terrax.net/
HTTP/1.1 301 Moved Permanently
4
https://wiki.terrax.net/wiki/Hauptseite
HTTP/1.1 200 OK

Analysis

Warning
Same-host permanent redirection
This is a little-bit unusual. There's a permanent redirection from a root to a specific path on the same site. This may cause problems if the subpath ever changes. A temporary redirection is more appropriate in this case.

From: https://wiki.terrax.net/

To: https://wiki.terrax.net/wiki/Hauptseite

WWW TLS

Transport Layer Security (TLS) is the most widely used encryption protocol on the Internet. In combination with valid certificates, servers can establish trusted communication channels even with users who have never visited them before. Network attackers can't uncover what is being communicated, even when they can see all the traffic.

Test passed
Everything seems to be well configured. Well done.

TLS Configuration: www.terrax.net (2a01:4f8:c0c:4f2e:0:0:0:2)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Unknown preference
Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca9
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc02c
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)

Analysis

Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Deprecated protocols not supported
Excellent. This server doesn't support any of the deprecated protocol (TLS 1.1 and earlier).
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Only strong suites supported
Excellent. This server supports only strong cipher suites, which use strong authenticated encryption and provide forward secrecy.
Good
All TLS connections satisfy Chrome's CT requirements
All TLS connections established with this server satisfy Chrome's CT requirements, using certificate, TLS extension, or OCSP response as SCT transport method.

SCT transport: CERT

TLS Configuration: www.terrax.net (94.130.231.169)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Unknown preference
Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca9
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc02c
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)

Analysis

Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Deprecated protocols not supported
Excellent. This server doesn't support any of the deprecated protocol (TLS 1.1 and earlier).
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Only strong suites supported
Excellent. This server supports only strong cipher suites, which use strong authenticated encryption and provide forward secrecy.
Good
All TLS connections satisfy Chrome's CT requirements
All TLS connections established with this server satisfy Chrome's CT requirements, using certificate, TLS extension, or OCSP response as SCT transport method.

SCT transport: CERT

TLS Configuration: terrax.net (94.130.231.169)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Unknown preference
Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca9
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc02c
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)

Analysis

Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Deprecated protocols not supported
Excellent. This server doesn't support any of the deprecated protocol (TLS 1.1 and earlier).
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Only strong suites supported
Excellent. This server supports only strong cipher suites, which use strong authenticated encryption and provide forward secrecy.
Good
All TLS connections satisfy Chrome's CT requirements
All TLS connections established with this server satisfy Chrome's CT requirements, using certificate, TLS extension, or OCSP response as SCT transport method.

SCT transport: CERT

TLS Configuration: terrax.net (2a01:4f8:c0c:4f2e:0:0:0:2)

Encryption protocol version determines what features are
available for negotiation between client and server.
Supported protocols
TLS v1.2
Servers should always enforce their own cipher
suite preference, as that is the only approach
that guarantees that the best possible suite is
selected.
Server suite preference
Shows cipher suite configuration for this protocol version.TLS v1.2
Unknown preference
Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
Suite ID: 0xcca9
Cipher name: CHACHA20
Cipher strength: 256 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
 256 bits (ECDHE 384 bits)
Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Suite ID: 0xc02c
Cipher name: AES
Cipher strength: 256 bits
Cipher block size: 128 bits
Cipher mode: AEAD
Key exchange: ECDHE_ECDSA
Key exchange strength: EC secp384r1 (384 bits)
Forward secrecy: Yes
PRF: SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 256 bits (ECDHE 384 bits)

Analysis

Good
TLS 1.2 supported
Excellent. This server support TLS 1.2, which is currently the only SSL and TLS protocol version that provides modern encryption facilities and doesn't have serious weaknesses.
Good
Deprecated protocols not supported
Excellent. This server doesn't support any of the deprecated protocol (TLS 1.1 and earlier).
Good
Strong key exchange detected
Excellent. All cipher suites on this server rely on strong key exchange. The sweet spot is 2048 bits for DHE and 256 bits for ECDHE. Putting ECDHE suites first guarantees best security and best performance.
Good
Only strong suites supported
Excellent. This server supports only strong cipher suites, which use strong authenticated encryption and provide forward secrecy.
Good
All TLS connections satisfy Chrome's CT requirements
All TLS connections established with this server satisfy Chrome's CT requirements, using certificate, TLS extension, or OCSP response as SCT transport method.

SCT transport: CERT

WWW Certificates

A certificate is a digital document that contains a public key, some information about the entity associated with it, and a digital signature from the certificate issuer. It’s a mechanism that enables us to exchange, store, and use public keys. Being able to reliably verify the identity of a remote server is crucial in order to achieve secure encrypted communication.

Test passed
Everything seems to be well configured. Well done.

Certificate: terrax.net

Leaf certificate terrax.net
Issuer: Let's Encrypt
Not Before: 09 Oct 2018 21:11:55 UTC
Not After: 07 Jan 2019 21:11:55 UTC (2 months 19 days)
Key: EC 384 bits
Signature: SHA256withRSA
 View details

Analysis

Good
Strong private key
Good. The private key associated with this certificate is secure.
Good
Strong signature algorithm
Good. This certificate uses a strong signature algorithm.
Good
Certificate matches hostname
Good. The provided certificate matches the expected hostnames.
Good
Certificate dates match
Good. The certificate is valid for use at this point of time.
Good
Certificate satisfies Chrome's CT requirements
This certificate contains embedded CT signatures and satisfies Chrome's CT requirements at this time.
Powerup!
Certificate doesn't require OCSP stapling
This certificate doesn't require OCSP stapling. If enabled, this feature increases the probability that a certificate will be considered revoked. This is a fairly new feature that is not yet very widely supported by various TLS clients. More information is available in RFC 7633.

Certificate Trust

Determining whether a certificate is considered valid is a complicated process that depends on the exact configuration of the validating party. For trust to be established, the certificate must form a chain that ends with a trusted root. In this section we evaluate the server's certificate against major root stores.

Platform Trusted
Apple iOS
Apple MacOS
Google AOSP
Microsoft
Mozilla

Certificate Chain

For a server certificate to be valid, it must be presented as part of a complete and valid certificate chain. The last certificate in the chain should be the root and is usually not included in the configuration.

Leaf certificate
terrax.net | 1740a7f
Not After: 07 Jan 2019 21:11:55 UTC (2 months 19 days)
Authentication: EC 384 bits (SHA256withRSA)
 View details
Intermediate certificate
Let's Encrypt Authority X3 | 25847d6   HPKP-PIN
Not After: 17 Mar 2021 16:40:46 UTC (2 years 4 months)
Authentication: RSA 2048 bits (SHA256withRSA)
 View details
Root certificate
DST Root CA X3 | 0687260
Not After: 30 Sep 2021 14:01:15 UTC (2 years 11 months)
Authentication: RSA 2048 bits (SHA1withRSA)
 View details

Analysis

Good
Certificate chain is correct
Good. This chain contains all the right certificates and in the right order.

Certificate: www.terrax.net

Leaf certificate terrax.net
Issuer: Let's Encrypt
Not Before: 09 Oct 2018 21:11:55 UTC
Not After: 07 Jan 2019 21:11:55 UTC (2 months 19 days)
Key: EC 384 bits
Signature: SHA256withRSA
 View details

Analysis

Good
Strong private key
Good. The private key associated with this certificate is secure.
Good
Strong signature algorithm
Good. This certificate uses a strong signature algorithm.
Good
Certificate matches hostname
Good. The provided certificate matches the expected hostnames.
Good
Certificate dates match
Good. The certificate is valid for use at this point of time.
Good
Certificate satisfies Chrome's CT requirements
This certificate contains embedded CT signatures and satisfies Chrome's CT requirements at this time.
Powerup!
Certificate doesn't require OCSP stapling
This certificate doesn't require OCSP stapling. If enabled, this feature increases the probability that a certificate will be considered revoked. This is a fairly new feature that is not yet very widely supported by various TLS clients. More information is available in RFC 7633.

Certificate Trust

Determining whether a certificate is considered valid is a complicated process that depends on the exact configuration of the validating party. For trust to be established, the certificate must form a chain that ends with a trusted root. In this section we evaluate the server's certificate against major root stores.

Platform Trusted
Apple iOS
Apple MacOS
Google AOSP
Microsoft
Mozilla

Certificate Chain

For a server certificate to be valid, it must be presented as part of a complete and valid certificate chain. The last certificate in the chain should be the root and is usually not included in the configuration.

Leaf certificate
terrax.net | 1740a7f
Not After: 07 Jan 2019 21:11:55 UTC (2 months 19 days)
Authentication: EC 384 bits (SHA256withRSA)
 View details
Intermediate certificate
Let's Encrypt Authority X3 | 25847d6   HPKP-PIN
Not After: 17 Mar 2021 16:40:46 UTC (2 years 4 months)
Authentication: RSA 2048 bits (SHA256withRSA)
 View details
Root certificate
DST Root CA X3 | 0687260
Not After: 30 Sep 2021 14:01:15 UTC (2 years 11 months)
Authentication: RSA 2048 bits (SHA1withRSA)
 View details

Analysis

Good
Certificate chain is correct
Good. This chain contains all the right certificates and in the right order.

DANE (443)

DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone.

Test passed
Everything seems to be well configured. Well done.

TLSA Record #1: _443._tcp.terrax.net.

Specifies which certificate in the chain
is being pinned and how validation should
be performed.
Certificate Usage
Domain-issued certificate / DANE-EE (3) Creates a leaf pin for a certificate that must be
present in the certificate chain. PKIX validation is
not performed and the pinned certificate is assumed
to be trusted.
Determines if the association is made with
a certificate or with a public key (via
its SPKI structure).
Selector
SPKI structure (1)
Determines how matching is done; directly or via a hash. Matching Type SHA2-512 (2)
Contains the data necessary to perform the matching. Data d0cc2f9957558d118caa9decf07911da87dc1b3b57aa1eeb6f4da9f3f45db1d1c5f4a1f72a14491032cfeff931de6bb8104ae390fa6118cf29f0e81572ae9e33

Leaf certificate: EC 384 bits
Subject: CN=terrax.net
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
terrax.net (EC 384 bits)

Analysis

Good
Valid DANE configuration
Excellent. Your DANE configuration matches the certificate chain(s) provided by the service. Your TLS configuration enjoys the additional benefit of DANE validation.

TLSA Record #2: _443._tcp.www.terrax.net.

Specifies which certificate in the chain
is being pinned and how validation should
be performed.
Certificate Usage
Domain-issued certificate / DANE-EE (3) Creates a leaf pin for a certificate that must be
present in the certificate chain. PKIX validation is
not performed and the pinned certificate is assumed
to be trusted.
Determines if the association is made with
a certificate or with a public key (via
its SPKI structure).
Selector
SPKI structure (1)
Determines how matching is done; directly or via a hash. Matching Type SHA2-512 (2)
Contains the data necessary to perform the matching. Data d0cc2f9957558d118caa9decf07911da87dc1b3b57aa1eeb6f4da9f3f45db1d1c5f4a1f72a14491032cfeff931de6bb8104ae390fa6118cf29f0e81572ae9e33

Leaf certificate: EC 384 bits
Subject: CN=terrax.net
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
terrax.net (EC 384 bits)

Analysis

Good
Valid DANE configuration
Excellent. Your DANE configuration matches the certificate chain(s) provided by the service. Your TLS configuration enjoys the additional benefit of DANE validation.

Cookies

Cookies are small chunks of text that are sent between your browser and a website. They are often essential to the operation of the site and sometimes contain sensitive information. Session cookies sent from secure sites must be explicitly marked as secure to prevent being obtained by active network attackers.

Test passed
Everything seems to be well configured. Well done.

Mixed Content

On virtually all web sites, HTML markup, images, style sheets, JavaScript, and other page resources arrive not only over multiple connections but possibly from multiple servers and sites spread across the entire Internet. For a page to be properly encrypted, it’s necessary that all the content is retrieved over HTTPS. In practice, that’s very often not the case, leading to mixed content security problems.

Test passed
Everything seems to be well configured. Well done.

Embedded Resources

In this section we look at the security of all embedded resources. Mixed active content occurs when there are unprotected scripts or styles embedded in a page. This is typically not allowed by modern browsers. Mixed passive content (images, videos and such) are typically allowed, but shouldn't be present.

0 script(s)
  0 out of 0 are secure
0 CSS file(s)
  0 out of 0 are secure
0 media file(s)
  0 out of 0 are secure

Outbound Links

Ideally, an encrypted page should only have links that lead to other encrypted pages. If plaintext links are used, passive network attackers can see where people go after they visit your web site. It's also possible that some sensitive information is leaked in the Referer header.

0 link(s)
  0 out of 0 are encrypted

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) vastly improves security of the network encryption layer. With HSTS enabled, browsers no longer allow clicking through certificate warnings errors, which are typically trivial to exploit. Additionally, they will no longer submit insecure (plaintext) requests to the site in question, even if asked.

Test passed
Everything seems to be well configured. Well done.

HSTS Policy  Main host

URL from which this policy was obtained.Location https://www.terrax.net
Specifies policy duration. Once activated, HSTS stays in force
until this time lapses. Browsers update policy cache duration
every time they receive a new HSTS header from a site.
max‑age
315,360,000 seconds (about 9 years 11 months)
When present, this directive forces HSTS activation
on allsubdomains. For best security, HSTS should be
deployed on the bare domain name (e.g., example.com)
and all its subdomains.
includeSubDomains
Presence of this directive indicates that a web site wishes to
permanently use HSTS and that its policy information should be
preloaded (embedded in browsers).
preload

Analysis

Good
Policy is valid
OK. Your HSTS policy uses correct syntax.
Good
Long policy age
Your HSTS policy has a long max-age value, which offers better protection.
Good
Policy covers subdomains
When subdomains are included, network attackers are unable to manufacture arbitrary subdomains to manipulate cookies and trick users.
Good
Redirection from HTTP to HTTPS to the same host
Good. The redirection from HTTP to HTTPS is to the same host. This approach ensures that HSTS is activated on the hostname when it's accessed via plaintext.
Good
Policy preloaded
Excellent. This host is covered by a preloaded HSTS policy.

Preloaded host: terrax.net; includeSubDomains=true

HSTS Policy  Apex host

URL from which this policy was obtained.Location https://terrax.net
Specifies policy duration. Once activated, HSTS stays in force
until this time lapses. Browsers update policy cache duration
every time they receive a new HSTS header from a site.
max‑age
315,360,000 seconds (about 9 years 11 months)
When present, this directive forces HSTS activation
on allsubdomains. For best security, HSTS should be
deployed on the bare domain name (e.g., example.com)
and all its subdomains.
includeSubDomains
Presence of this directive indicates that a web site wishes to
permanently use HSTS and that its policy information should be
preloaded (embedded in browsers).
preload

Analysis

Good
Policy is valid
OK. Your HSTS policy uses correct syntax.
Good
Long policy age
Your HSTS policy has a long max-age value, which offers better protection.
Good
Policy covers subdomains
When subdomains are included, network attackers are unable to manufacture arbitrary subdomains to manipulate cookies and trick users.
Good
Preload intent declared
Good. With the preload directive set, browsers have a green light to embed the HSTS policy.
Good
Redirection from HTTP to HTTPS to the same host
Good. The redirection from HTTP to HTTPS is to the same host. This approach ensures that HSTS is activated on the hostname when it's accessed via plaintext.
Good
Policy preloaded
Excellent. This host is covered by a preloaded HSTS policy.

Preloaded host: terrax.net; includeSubDomains=true

HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP) enables site operators to restrict which certificates are considered valid for their domain names. With a valid HPKP configuration, sites can defeat man in the middle (MITM) attacks using fraudulent or misissued certificates. HPKP is an advanced feature, suitable for use by only high-profile web sites.

Test passed
Everything seems to be well configured. Well done.

HPKP Policy (Enforcing)

Specifies the number of seconds after the reception
of the HPKP header during which the user agent should
enforce pinning. Has no meaning in a report-only policy.
max‑age
604,800 seconds (about 7 days)
This directive signals to the user agent that
the pinning policy applies to the current host
as well as all its subdomains.
includeSubDomains
Specifies a cryptographic identity that should
be bound to the given web host. The binding is
done via the hash of the desired public key.
pin-sha256
C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
Specifies a cryptographic identity that should
be bound to the given web host. The binding is
done via the hash of the desired public key.
pin-sha256
YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=

Root certificate: RSA 2048 bits
Subject: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co.
Let's Encrypt Authority X3 (RSA 2048 bits)

Specifies a cryptographic identity that should
be bound to the given web host. The binding is
done via the hash of the desired public key.
pin-sha256
sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=

Analysis

Powerup!
Policy doesn't use reporting
When the reporting functionality is enabled, browsers submit reports describing policy violations to an endpoint of your choice. This is very useful, not only because you can keep an eye on the possible attacks, but also as a way of detect pinning configuration issues.

Analysis

Info
Enforcing policy discovered

Header: Public-Key-Pins

Value: max-age=604800; includeSubDomains; pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis="

Good
Enforcing policy is valid
Good. Your policy uses the correct syntax.

Content Security Policy

Content Security Policy (CSP) is a security mechanism that allows web sites control how browsers process their pages. In essence, sites can restrict what types of resources are loaded and from where. CSP policies can be used to defend against cross-site scripting, prevent mixed content issues, as well as report violations for investigation.

Test passed
Everything seems to be well configured. Well done.

Content-Security-Policy

default-src 'self'  
connect-src 'self'   https://*.akamaihd.net  
media-src 'self'   https://*.akamaihd.net  
object-src 'none'
frame-ancestors 'none'  
form-action 'self'  
block-all-mixed-content -

Analysis

Good
All mixed content is blocked
Good. This CSP policy blocks all mixed content, which includes insecure images that browsers allow.

Analysis

Info
CSP policy detected

Header: Content-Security-Policy

Value: default-src 'self'; connect-src 'self' https://*.akamaihd.net; media-src 'self' https://*.akamaihd.net; object-src 'none'; frame-ancestors 'none'; form-action 'self'; block-all-mixed-content; disown-opener;

Location: https://terrax.net/

Subresource Integrity

Subresource Integrity (SRI) is a new standard that enables browsers to verify the integrity of embedded page resources (e.g., scripts and stylesheets) when they are loaded from third-party web sites. With SRI deployed, remote resources can be used safely, without fear of them being modified by malicious parties.

Test passed
Everything seems to be well configured. Well done.
No external scripts
  SRI not needed
No external stylesheets
  SRI not needed

Analysis

Good
No remote resources
The homepage of this site doesn't contain any remote resources so SRI is not needed.

Expect CT

Expect-CT is a response HTTP header that web sites can use to monitor problems related to their Certificate Transparency (CT) compliance. Additionally, they can also instruct browsers to reject any certificates in their name that are are not CT-compliant.

Test passed
Everything seems to be well configured. Well done.

Expect-CT Policy

URL from which this policy was obtained.Location https://terrax.net/
Specifies policy duration. Once activated, Expect-CT stays in force
until this time lapses. Browsers update policy cache duration
every time they receive a new Expect-CT header from a site.
max‑age
604,800 seconds (about 7 days)
This optional directive controls whether CT compliance
will be enforced by your policy. It's useful if you're
confident in your configuration and wish to deploy CT
before browsers start enforcing it.
enforce
This optional directive enables reporting and specifies
the endpoint clients should use to submit reports.
report-uri

Analysis

Powerup!
Deploy Expect-CT reporting
This policy doesn't use reporting, which means that you will not found out about any problems with CT compliance. We recommend adding the reporting for better situational awareness.

Analysis

Info
Header information

Policy text: max-age=604800, enforce

Good
Expect-CT enabled
Excellent. This web site has a valid Expect-CT policy.

Frame Options

The X-Frame-Options header controls page framing, which occurs when a page is incorporated into some other page, possibly on a different site. If framing is allowed, attackers can employ clever tricks to make victims perform arbitrary actions on your site; they do this by showing their web site while forwarding the victim's clicks to yours.

Test passed
Everything seems to be well configured. Well done.

Analysis

Info
Header information

Name: X-Frame-Options

Value: SAMEORIGIN

Good
Framing allowed from the same origin only
OK. Your site allows page framing only from itself. This should generally be safe, except maybe on sites that host user content.

XSS Protection

Modern browsers ship with built-in defenses against Cross-Site Scripting (XSS), usually known as XSS Auditors. Web sites are allowed to control the defenses if they specify an X-XSS-Protection header in their HTTP responses. Recommended policies are either to block XSS attacks, or disable the defenses if you think false positives are possible. Filtering, where offending fragments of data are removed, is not recommended because it can be abused by attackers to selectively deactivate script files.

Test passed
Everything seems to be well configured. Well done.

Analysis

Info
Header information

Name: X-XSS-Protection

Value: 1; mode=block

Good
Valid configuration
Good. Your configuration enforces blocking when XSS attacks are detected.

Content Type Options

Some browsers use a technique called content sniffing to override response MIME types provided by HTTP servers and interpret responses as something else (usually HTML). This behavior, which could potentially lead to security issues, should be disabled by attaching an X-Content-Type-Options header to all responses.

Test passed
Everything seems to be well configured. Well done.

Analysis

Info
Header information

Name: X-Content-Type-Options

Value: nosniff

Good
Valid configuration
Good. Your configuration is valid. This means that browsers won't try to guess file MIME type on this web site.

HTML Analysis

Analysis of page content, including SRI.

Test passed
Everything seems to be well configured. Well done.

Base URL

https://terrax.net/

Active Content

Type Status Location
None

Passive Content

Type Status Link
None

Links

Type Status Link
None