Jump to content
nsane.forums

Search the Community

Showing results for tags 'https'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Found 2 results

  1. In conjunction with the Cybersecurity Awareness Month celebration in October last year, Google shared some statistical data about how HTTPS usage in Chrome increased across different platforms. Since its inception, Chrome traffic encryption efforts have made significant progress that Google now wants to remove the green “Secure” label on HTTPS websites beginning in September once the search giant launches Chrome 69. The goal of the upcoming change to the browser is to give users the idea that the internet is safe by default by eliminating Chrome’s positive security indicators. Here's how the address bar should look like after the new scheme kicks off in September: Emily Schechter, Product Manager for Chrome Security at Google, also announced in a blog post that starting in October the company will mark all HTTP pages with a red “not secure” warning in the event that a user enters data on an HTTP page. The new label will be part of Chrome 70, which is set for release that month. That's in line with the search giant's upcoming plan, announced last February, to show a grey "not secure" warning in the address bar for HTTP pages starting in July when Chrome 68 is set to roll out. Source details < Clic here >
  2. Let's Encrypt – a SSL/TLS certificate authority run by the non-profit Internet Security Research Group (ISRG) to programmatically provide websites with free certs for their HTTPS websites – on Thursday said it is discontinuing TLS-SNI validation because it's insecure in the context of many shared hosting providers. TLS-SNI is one of three ways Let's Encrypt's Automatic Certificate Management Environment protocol validates requests for TLS certificates, which enable secure connections when browsing the web, along with the confidence-inspiring display of a lock icon. The other two validation methods, HTTP-01 and DNS-01, are not implicated in this issue. The problem is that TLS-SNI-01 and its planned successor TLS-SNI-02 can be abused under specific circumstances to allow an attacker to obtain HTTPS certificates for websites that he or she does not own. Such a person could, for example, find an orphaned domain name pointed at a hosting service, and use the domain – with an unauthorized certificate to make fake pages appear more credible – without actually owning the domain. For example, a company might have investors.techcorp.com set up and pointed at a cloud-based web host to serve content, but not investor.techcorp.com. An attacker could potentially create an account on said cloud provider, and add a HTTPS server for investor.techcorp.com to that account, allowing the miscreant to masquerade as that business – and with a Let's Encrypt HTTPS cert, too, via TLS-SNI-01, to make it look totally legit. It sounds bonkers but we're told some cloud providers allow this to happen. And that's why Let's Encrypt ditched its TLS-SNI-01 validation processor. Ownership It turns out that many hosting providers do not validate domain ownership. When such providers also host multiple users on the same IP address, as happens on AWS CloudFront and on Heroku, it becomes possible to obtain a Let's Encrypt certificate for someone else's website via the TLS-SNI-01 mechanism. On Tuesday, Frans Rosén, a security researcher for Detectify, identified and reported the issue to Let's Encrypt, and the organization suspended certificate issuance using TLS-SNI-01 validation, pending resolution of the problem. In his account of his proof-of-concept exploit, Rosén recommended three mitigations: disabling TLS-SNI-01; blacklisting .acme.invalid in certificate challenges, which is required to get a cert via TLS-SNI-01; and looking to other forms of validation because TLS-SNI-01 and 02 are broken given current cloud infrastructure practices. AWS CloudFront and Heroku have since tweaked their operations based on Rosén's recommendation, but the problem extends to other hosting providers that serve multiple users from a single IP address without domain ownership validation. Late Thursday, after temporarily reenabling the validation method for certain large hosting providers that aren't vulnerable, Let's Encrypt decided it would permanently disable TLS-SNI-01 and TLS-SNI-02 for new accounts. Those who previously validated using TLS-SNI-01 will be allowed to renew using the same mechanism for a limited time. "We have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation," said ISRG executive director Josh Aas in a forum post. "There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation." Aas stressed that Let's Encrypt will discontinue using the TLS-SNI-01 and TLS-SNI-02 validation methods Article
×