Política de Privacidade

Este site utiliza Cookies. Ao navegar, está a consentir o seu uso. Saiba mais

Compreendi

Resultados: www.bitwoci.pt

https://www.webcheck.pt/pt/resultados/www.bitwoci.pt/

Resultados obtidos em : 2025-05-09 08:37:18

Segundos até nova atualização:

110

Página de Internet (Website)

Configuração e segurança do domínio

DNSSEC
DNSSEC (Domain Name System Security Extensions) é o nome dado às extensões de segurança ao protocolo DNS concebidas para proteger e autenticar o tráfego DNS. Estas extensões fazem uso da tecnologia de criptografia assimétrica para assegurar a autenticidade e a integridade da informação trocada entre servidores DNS e entre estes e as aplicações do utilizador.  

Para uma melhor compreensão e correta implementação de DNSSEC poderá consultar o documento "Tutorial DNSSEC" (Associação DNS.PT, 2019).
Através deste teste é verificado se o nome de domínio se encontra assinado com DNSSEC. A correta implementação de DNSSEC impede a manipulação das respostas DNS, o que poderia conduzir a um redirecionamento não autorizado de pedidos para um servidor controlado por terceiros.

O nome de domínio encontra-se assinado com DNSSEC.

Neste teste é verificado se o nome de domínio se encontra assinado com uma assinatura válida DNSSEC e marcado como 'secure'.

O nome de domínio encontra-se configurado de forma segura. A assinatura DNSSEC é válida.

DANE
DANE (DNS-based Authentication of Named Entities) consiste num protocolo que adiciona uma camada adicional de proteção ao serviço web, uma vez que permite especificar, de forma segura, informação sobre o certificado que deverá ser utilizado para acesso ao seu website.  

A utilização de DANE depende da implementação de DNSSEC.

Para mais informações sobre a implementação de STARTLS e DANE poderá consultar o documento "Recomendação Técnica 01/21 – STARTTLS e DANE" (CNCS, 2021).
Através deste teste é verificada a existência de um registo TLSA  assinado para cada um dos servidores web do domínio de Internet. 

Uma vez que a correta configuração de DANE depende da implementação de DNSSEC, este teste não será executado caso o domínio não se encontre configurado com DNSSEC.

Todos os servidores web do domínio de Internet têm associado um registo TLSA.

Detalhes técnicos:

_443._tcp.www.bitwoci.pt. 300 IN TLSA 3 1 1 1EDCD5547CB1CCBBC94CB6F643F59F20EFFBC45CB5AA9400E98BD151 01B2DB07

Neste teste é verificado se a síntese (hash) DANE publicada no(s) registo(s) TLSA correponde ao(s) certificado(s) digitais apresentado(s) pelo(s) servidor(es) web. 

A síntese do certificado digital apresentada pelo(s) servido(res) web (A) corresponde ao apresentado no registo TLSA.

Segurança da ligação

HTTP/S
O protocolo HTTPS (Hyper Text Transfer Protocol Secure) representa uma camada adicional de segurança ao protocolo HTTP. A utilização de HTTPS ao nível de um domínio de internet impede que a comunicação entre o navegador (browser) e o servidor da página de internet possa ser intercetada e/ou manipulada por terceiros.
Neste teste é verificado se o domínio de internet disponibiliza o protocolo seguro HTTPS para comunicação.

Existe um canal que permite a comunicação segura entre o navegador de internet (browser) e o servidor que disponibiliza a página de internet.

Detalhes técnicos:

109.71.41.233: HTTPS Enabled

Neste teste é verificado se o domínio de internet reencaminha automaticamente as comunicações de HTTP para HTTPS (no mesmo domínio e através do código 301) ou se apenas suporta o protocolo seguro HTTPS.

Existe um redirecionamento ativo das comunicações para o canal seguro (HTTPS).

HSTS
HSTS (HTTP Strict-Transport-Security) consiste num cabeçalho de resposta que permite a um domínio de internet comunicar aos navegadores (browsers) que só deverá ser acedido através do protocolo HTTPS, evitando assim a utilização de canais inseguros e vulneráveis a interceção e manipulação por terceiros.
Neste teste é verificado se o domínio de internet suporta HSTS.

Para cumprir esta validação é necessária a correta implementação do cabeçalho HSTS com um valor de "max-age" superior a 6 meses. Caso o valor de "max-age" seja inferior a 6 meses, apenas cumprirá parcialmente este teste.

O domínio de internet possui suporte a HSTS, com um "max-age" superior a 6 meses.

Detalhes técnicos:

HSTS Header: max-age=63072000; includeSubDomains; preload

Neste teste é verificado se o domínio de internet se encontra configurado com pré-carregamento (preload) de HSTS.

O pré-carregamento de HSTS permite colocar o domínio numa lista incorporada nos navegadores de internet (browsers). Caso o domínio se encontre presente nessa lista, sempre que alguém visite a página de internet associada ao mesmo, será automaticamente encaminhado para um canal seguro (HTTPS). Esta funcionalidade é adotada pelos navegadores de internet mais utilizados atualmente, como o Chrome, Firefox e Safari.

Após implementar corretamente o cabeçalho HSTS, pode solicitar a incorporação do seu domínio na respetiva lista através de: https://hstspreload.org/.

O domínio de internet encontra-se configurado com pré-carregamento (preload) de HSTS .

TLS
TLS (Transport Layer Security) é um protocolo criptográfico projetado para fornecer segurança nas comunicações. A utilização de versões consideradas seguras do protocolo TLS, em combinação com a utilização de certificados digitais válidos, permite fornecer aos visitantes de um domínio de internet um maior grau de segurança na ligação estabelecida.
Através deste teste verifica-se se o domínio de internet suporta versões consideradas inseguras do protocolo TLS.

As versões mais antigas de TLS (SSL v2.0, v3.0 e TLS v1.0) contêm diversas vulnerabilidades, pelo que não devem ser adotadas. A utilização do protocolo TLS v1.1 é considerado um cumprimento parcial do teste, sendo aconselhada a transição para a versão TLS v1.2 e/ou superior (que representam um cumprimento total da verificação).

O domínio de internet apenas suporta versões do protocolo de comunicação TLS consideradas seguras.

Detalhes técnicos:

www.bitwoci.pt: SSLv2:false | SSLv3:false | TLSv1.0:false | TLSv1.1:false | TLSv1.2:true | TLSv1.3:true

Este teste verifica se o(s) servidor(es) web do domínio de Internet suportam a renegociação segura do protocolo TLS.

As versões mais antigas do protocolo TLS (anteriores à versão 1.3) permitem forçar uma renegociação de protocolo, funcionalidade potencialmente insegura nas versões originais do protocolo e que foi corrigida em versões mais recentes através da implementação de um mecanismo de renegociação mais seguro. A versão antiga é chamada de renegociação insegura e deve ser desabilitada.

O(s) servidor(es) web do domínio de Internet suportam a renegociação segura do protocolo TLS.

Certificado Digital
Um certificado digital (também conhecido por certificado SSL/TLS ou de chave pública) consiste num documento eletrónico, assinado digitalmente por uma entidade certificadora, que liga a chave pública da entidade a que se destina aos seus dados de identificação e é utilizado para garantir a sua identidade em transações eletrónicas.
Através deste teste é verificado se o certificado digital associado ao domínio não se encontra expirado.

Para cumprir totalmente esta validação, o certificado digital deve apresentar uma data de expiração superior a 30 dias.

O certificado digital associado ao domínio de internet não se encontra expirado e tem um período de validade superior a 30 dias.

Detalhes técnicos:

www.bitwoci.pt: 21-01-2026

Neste teste é verificado se o certificado digital associado ao domínio é reconhecido pela maioria dos navegadores de internet (browsers) e se se encontra corretamente configurado.

Para cumprir na totalidade esta validação, o certificado não pode ser auto assinado, deve ser reconhecido pela "Root CA" e apresentar corretamente os certificados intermédios.

A cadeia do certificado digital é válida e não apresenta erros de configuração.

Detalhes técnicos:

Self Signed Cert:false | HTTPS Bad Chain:false | HTTPS Probably Missing Intermediate Cert:false | HTTPS Publicly Trusted:true

Opções de segurança

Cabeçalhos de segurança
Para além do cabeçalho de segurança HSTS, consideram-se ainda outros cabeçalhos HTTP que podem contribuir para aumentar a segurança associada a um domínio de internet.
Neste teste é verificado se o domínio de internet suporta o cabeçalho de segurança "X-Content-Type-Options", com a opção "nosniff".

Ao utilizar esta opção o navegador de internet (browser) irá bloquear solicitações de "styles" e "scripts" sempre que estes não tiverem um tipo de conteúdo correspondente. Por exemplo, um "style" em que o tipo MIME não é "text/css".

O domínio de internet possui suporte ao cabeçalho de segurança "X-Content-Type-Options", com a opção "nosniff".

Detalhes técnicos:

Header: nosniff

Neste teste é verificado se o domínio de internet suporta o cabeçalho de segurança "X-Frame-Options". Este cabeçalho permite controlar se a página de internet associada ao domínio pode ser incluída dentro de outra página de internet (ou seja, "framed"), podendo ser implementado através de tês opções distintas:

1. "deny", indicando que o domínio de internet nunca pode ser "framed" dentro de uma página de internet associada a outro domínio;
2. "sameorigin", indicando que o domínio de internet só pode ser "framed" dentro de uma página de internet do próprio domínio;
3. "allow-from", indicando que o domínio de internet só pode ser "framed" dentro de uma página de internet pertencente ao(s) domínio(s) indicado(s).

O domínio de internet possui suporte ao cabeçalho de segurança "X-Frame-Options".

Detalhes técnicos:

Header: SAMEORIGIN

Neste teste é verificado se o domínio de internet suporta o cabeçalho de segurança "Referrer-Policy". Este cabeçalho é utilizado para controlar que tipo de informação é enviada através do campo "Referer".

Este cabeçalho pode ser implementado através das seguintes opções:
1. "no-referrer", onde toda a informação "Referer" é omitida;
2. "no-referrer-when-downgrade" (opção por omissão), onde a informação "Referer" é apenas enviada quando é mantido o mesmo nível de segurança (HTTP -> HTTP ou HTTPS -> HTTPS);
3. "origin", onde a informação enviada em "Referer" é apenas relativa à origem, por exemplo, o documento https://exemplo.pt/página envia como "Referer" o valor "https://exemplo.pt/";
4. "origin-when-cross-origin", onde a informação de "Referer" é enviada na totalidade quando dentro do mesmo domínio, mas apenas a origem quando para outros domínios;
5. "same-origin", onde a informação de "Referer" é apenas enviada dentro do mesmo domínio;
6. "strict-origin", onde a informação de "Referer" é apenas relativa à origem e só enviada quando se mantém o mesmo nível de segurança;
7. "strict-origin-when-cross-origin", onde a informação de "Referer" é enviada na totalidade quando dentro do mesmo domínio, mas apenas a origem quando para outros domínios e mantendo o nível de segurança;
8. "unsafe-url", onde a informação de "Referer" é enviada na totalidade para qualquer domínio.

O domínio de internet possui suporte ao cabeçalho de segurança "Referrer-Policy".

Detalhes técnicos:

Header: strict-origin

Através deste teste é verificado se o domínio de internet suporta o cabeçalho de segurança "Content-Security-Policy". Este cabeçalho permite definir como e de que origem são processados os recursos utilizados pela página de internet, como por exemplo, javascript e CSS. A utilização deste cabeçalho previne ataques de cross-site scripting (XSS), impedido a injeção de código a partir de origens desconhecidas.

O domínio de internet tem suporte ao cabeçalho de segurança "Content-Security-Policy".

Detalhes técnicos:

Header: ["object-src 'none'; block-all-mixed-content; upgrade-insecure-requests; report-uri https://bitwoci.report-uri.com/r/d/csp/enforce"]

Correio Eletrónico

Configuração e segurança do domínio de correio eletrónico

DNSSEC
DNSSEC (Domain Name System Security Extensions) é o nome dado às extensões de segurança ao protocolo DNS concebidas para proteger e autenticar o tráfego DNS. Estas extensões fazem uso da tecnologia de criptografia assimétrica para assegurar a autenticidade e a integridade da informação trocada entre servidores DNS e entre estes e as aplicações do utilizador.  

Para uma correta implementação de DNSSEC poderá consultar o documento "Tutorial DNSSEC" (Associação DNS.PT, 2019).
Através deste teste é verificado se o(s) nome(s) de domínio(s) do(s) servidor(es) de correio eletrónico (MX) se encontra(m) assinado(s) com DNSSEC. A correta implementação de DNSSEC impede a manipulação das respostas DNS, o que poderia conduzir a um redirecionamento não autorizado de mensagens para um servidor controlado por terceiros.

O(s) nome(s) de domínio do(s) servidor(es) de correio eletrónico (MX) encontram-se assinados com DNSSEC.

Neste teste é avaliado se o(s) nome(s) de domínio do(s) servido(res) de correio eletrónico (MX) se encontram assinados com uma assinatura DNSSEC válida e marcados como "secure".

O(s) nome(s) de domínio do(s) servidor(es) de correio eletrónico (MX) encontram-se configurados corretamente. A assinatura DNSSEC é válida.

Autenticação e Integridade

SPF
O SPF (Sender Policy Framework) consiste num standard de validação do canal de envio de correio eletrónico, baseado na utilização do serviço de nomes de domínio (DNS) para publicação dos endereços IP dos servidores autorizados a enviar correio eletrónico para o respetivo domínio. Trata-se de um método que permite ao detentor de um domínio especificar que servidor (ou servidores) de correio eletrónico têm permissão para o envio de mensagens e a subsequente verificação pelo servidor de destino.

Para mais informações sobre a implementação de SPF poderá consultar o documento "Recomendação Técnica 01/19 - SPF, DKIM e DMARC" (CNCS, 2019).
Através deste teste é verificado se o domínio de correio eletrónico possui um registo SPF.

O domínio de correio eletrónico possui um registo SPF.

Detalhes técnicos:

SPF Record: v=spf1 a:mail.bithosting.pt a:mail2.bithosting.pt +include:_spf.bithosting.pt -all

Neste teste é verificado se o domínio de correio eletrónico possui uma política de SPF suficientemente restrita. 

O cumprimento total do teste requer a implementação de uma política "hardfail". A implementação de uma política "softfail" irá implicar o cumprimento parcial do teste. As restantes configurações de políticas SPF ou uma incorreta configuração do registo (por exemplo, através da necessidade de resolução de mais de dez registos de DNS) resultam no incumprimento do teste.

O domínio de correio eletrónico implementa uma política SPF válida e suficientemente segura.

DKIM
A utilização de DKIM (DomainKeys Identified Mail) visa disponibilizar um método para validação de uma identidade digital associada a uma mensagem (tipicamente o domínio do remetente). O objetivo é o não repúdio da atribuição da mensagem, conseguido através da aposição de uma assinatura criptográfica a cada mensagem enviada. O DKIM utiliza criptografia de chave pública, o que significa que existe uma chave privada que apenas o assinante da mensagem conhece, e uma chave pública que todos conhecem e pode ser utilizada para verificar a mensagem. 

Para mais informações sobre a implementação de DKIM poderá consultar o documento "Recomendação Técnica 01/19 - SPF, DKIM e DMARC" (CNCS, 2019).
Neste teste é verificado se o domínio de correio eletrónico possui um registo/chave DKIM. Um servidor de correio eletrónico recetor pode utilizar este registo para verificar a autenticidade e integridade da mensagem recebida. No entanto, através deste teste não é possível verificar a validade da chave DKIM, pois para isso seria necessário conhecer o respetivo seletor DKIM (que só se encontra presente nos cabeçalhos das mensagens enviadas a partir do respetivo domínio).

Para cumprir na totalidade os requisitos desta validação, e considerando o RFC2308, espera-se que o servidor de nomes do domínio responda "NOERROR" à consulta de "_domainkey.<nome_de_domínio>". Caso a resposta seja "NXDOMAIN" considera-se que o teste não foi cumprido.

O domínio de correio eletrónico possui um registo DKIM configurado.

DMARC
O DMARC (Domain-based Message Authentication, Reporting & Conformance) depende da correta implementação de SPF e DKIM e unifica estes dois mecanismos de autenticação numa framework comum que permite aos responsáveis de cada domínio definirem de que forma é que uma mensagem de correio eletrónico desse domínio deve ser tratada caso falhe um teste de autorização. Quem implementa DMARC beneficia ainda da capacidade de ter uma maior visibilidade sobre os e-mails legítimos e ilegítimos enviados através do seu nome de domínio de correio eletrónico.

Para mais informações sobre a implementação de DMARC poderá consultar o documento "Recomendação Técnica 01/19 - SPF, DKIM e DMARC" (CNCS, 2019).
Neste teste é verificado se o domínio de correio eletrónico possui um registo DMARC. A política DMARC define a forma como um servidor de correio eletrónico recetor deve atuar quando identifica uma mensagem que se encontra em incumprimento com a política de SPF e/ou DKIM definida para o domínio emissor.

O domínio de correio eletrónico tem associado um registo DMARC.

Detalhes técnicos:

DMARC Record: v=DMARC1; p=reject; rua=mailto:bitwoci-d@dmarc.report-uri.com; ruf=mailto:bitwoci-d@dmarc.report-uri.com; sp=reject; adkim=s; aspf=s; fo=0:1:d:s; rf=afrf; pct=100; ri=86400

Neste teste é verificado se o domínio de correio eletrónico possui uma política DMARC suficientemente restrita. O cumprimento total do teste requer a implementação do DMARC com uma política de rejeição ou de quarentena ("p=reject" ou "p=quarantine"). Quando aplicada a política de não ação ("p=none"), a validação é parcialmente cumprida.

O DMARC, através da definição das opções "rua=" e "ruf=", possibilita ainda a receção de relatórios agregados de conformidade ("rua") e forenses ("ruf"), os quais permitem analisar o grau de utilização ilegítima do domínio de correio eletrónico.

O domínio de correio eletrónico implementa uma política DMARC segura.

Detalhes técnicos:

DMARC Policy: reject

Confidencialidade

STARTTLS
O STARTTLS consiste numa extensão do protocolo de transporte de correio eletrónico SMTP (Simple Mail Transfer Protocol) que permite a utilização do TLS (Transport Layer Security) de modo a garantir uma comunicação segura e autenticada entre dois dispositivos que pretendem trocar uma mensagem de correio eletrónico. A utilização de STARTTLS visa assim evitar que as mensagens de correio eletrónico possam ser interceptadas e/ou manipuladas no caminho até ao seu destino final.

Para mais informações sobre a implementação de STARTLS e DANE poderá consultar o documento "Recomendação Técnica 01/21 – STARTTLS e DANE" (CNCS, 2021).
Neste teste é verificado se o(s) servidor(es) de correio eletrónico associado(s) ao domínio suporta(m) uma ligação STARTTLS. Caso seja suportada, será testada de seguida a conformidade das versões do protocolo TLS associadas a essa ligação.

O(s) servidor(es) de correio eletrónico associado(s) ao domínio suporta(m) ligações STARTTLS.

Detalhes técnicos:

mx1.mailchannels.net:25, mx2.mailchannels.net:25

Através deste teste verificamos se o(s) servidor(es) de correio eletrónico associado(s) ao nome de domínio suporta(m) versões consideradas seguras do protocolo TLS. 

As versões mais antigas de TLS (SSL v2.0, v3.0 e TLS v1.0) contêm diversas vulnerabilidades, pelo que não devem ser adotadas. A utilização do protocolo TLS v1.1 é considerado um cumprimento parcial do teste, sendo aconselhada a transição para a versão TLS v1.2 e / ou superior (que representam um cumprimento total da verificação).

O(s) servidor(es) de correio eletrónico associado(s) ao domínio suporta(m) versões de TLS consideradas seguras.

Detalhes técnicos:

mx1.mailchannels.net: SSLv2:false | SSLv3:false | TLSv1.0:false | TLSv1.1:false | TLSv1.2:true | TLSv1.3:true
mx2.mailchannels.net: SSLv2:false | SSLv3:false | TLSv1.0:false | TLSv1.1:false | TLSv1.2:true | TLSv1.3:true

DANE
DANE (DNS-based Authentication of Named Entities) consiste num protocolo que adiciona uma camada adicional de proteção ao serviço de correio eletrónico, uma vez que permite especificar, de forma segura, informação sobre o certificado que deverá ser utilizado na comunicação STARTTLS entre servidores. 

A utilização de DANE depende da implementação de DNSSEC.

Para mais informações sobre a implementação de STARTLS e DANE poderá consultar o documento "Recomendação Técnica 01/21 – STARTTLS e DANE" (CNCS, 2021).
Através deste teste é verificada a existência de um registo TLSA  assinado para o(s) servidor(es) de correio eletrónico do domínio. 

Uma vez que a correta configuração de DANE depende da implementação de DNSSEC, este teste não será executado caso o domínio não se encontre configurado com DNSSEC.

Pelo menos um dos servidores de correio eletrónico do domínio não tem associado um registo TLSA.

Neste teste é verificado se a síntese (hash) DANE publicada no(s) registo(s) TLSA correponde ao(s) certificado(s) TLS apresentado(s) pelo(s) servidor(es) de correio eletrónico.

Este teste não foi efetuado por não existirem condições técnicas para a sua realização ou porque depende de um teste que falhou anteriormente.

Cumpre

Cumpre parcialmente

Não cumpre

Teste não efetuado

Recomendações