Jump to content

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 14 results

  1. Linux documentation switches to HTTPS to boost security Several commits have been made to the Linux kernel in recent days and weeks which switch links in the kernel’s documentation from HTTP to the more secure HTTPS protocol. According to commit logs made by Alexander Klimov, the switch to HTTPS should reduce the likelihood of man-in-the-middle attacks against kernel developers. To ensure that links do not break when switched to the more secure protocol, tests were run to ensure pages loaded in the same manner. While it’s a welcome change which should boost the security of the whole Linux community, the move is a proactive one according to Phoronix which said that there has been no sign of any kernel developers being attacked recently via URLs. These new security enhancements should become available to developers once Linux 5.9 has been released, the latest version of the kernel so far is version 5.8-rc6. Depending on how things go, Linux 5.8 should be released on one of the upcoming Sundays before Linux 5.9 enters the release candidate phase for a final round of testing. Each new Linux kernel update usually brings new hardware support and new software features. New kernels are typically released every two months give or take a few weeks if more polish is needed. Source: Phoronix Linux documentation switches to HTTPS to boost security
  2. Firefox 80: HTTPS-only Mode in Settings Mozilla added an optional HTTPS-only mode to Firefox 76 Nightly back in March 2020. The organization's engineers have now added the mode to the settings of Firefox 80 Nightly, and it is likely that users of other Firefox channel versions, e.g. Firefox Stable, will be able to configure the mode once their version of the browser is updated to Firefox 80. HTTPS-Only Mode is designed to enforce HTTPS on sites. It works similarly to HTTPS Everywhere and other HTTPS upgrade extensions for browsers in that it attempts to upgrade HTTP connections, that are not secure, to HTTPS connections, which are. The core difference between the native HTTPS-Only Mode and extensions is that Mozilla's implementation attempts to upgrade every HTTP connection to HTTPS. HTTPS Everywhere uses a list for the upgrades that rewrite connections on sites that are opened in the browser. Firefox's HTTPS-Only Mode applies the upgrade to all HTTP connections, even if an HTTPS option is not available; this may lead to loading errors that can range from sites not loading at all to content on the site becoming unavailable. Firefox informs the user if the entire site could not be loaded because it does not support HTTPS. The same is not true for elements that may not be loaded on a site, though. Up until now, Nightly users had to set the value of the preference dom.security.https_only_mode to TRUE to enable the feature in the browser. A value of FALSE, the default, disables the HTTP to HTTPS upgrade enforcement in the browser. Starting in Firefox 80, that is no longer necessary but still available. Mozilla added options to control the browser's HTTPS-Only Mode in the options. Load about:preferences#privacy in the browser's address bar and scroll all the way down to the HTTPS-Only Mode group. The feature is set to "Don't enable HTTPS-Only Mode" by default. Switch it to Enable HTTPS-Only Mode in all windows to enable it everywhere, or Switch it to Enable HTTPS-Only Mode in private windows only, to only enable it for private browsing. A restart is not required. When you enable the option, Firefox will rewrite HTTP links to HTTPS automatically. Closing Words When Mozilla launched the HTTP upgrade mode in Firefox 76, I concluded that it could be useful in some situations, e.g. when using profiles in Firefox and using one of the profiles for secure activities such as online banking. The downside to enabling the mode is that it may break functionality on some sites, and some sites entirely. Since there is no simply "turn off mode on this page" option, it is quite cumbersome to deal with the issue when it is encountered. I find it puzzling that the option is added to the browser's preferences, considering that Mozilla's stance in the past was to limit user exposure to settings that could potentially impact the accessibility of sites. I think it would be better if Mozilla would integrate HTTPS Everywhere in the browser, maybe even with an option to enforce HTTPS everywhere. The extension is already included in the Tor Browser by default. Firefox 80: HTTPS-only Mode in Settings
  3. Firefox 76 gets optional HTTPS-only mode Mozilla plans to introduce an optional HTTPS-only mode in Firefox 76 which only allows connections to HTTPS sites. Most Internet sites use HTTPS already to improve the security of connections. HTTPS encrypts the connection which protects against manipulation and also blocks the logging of activity. Firefox users may soon enable an option in the web browser to allow only HTTPS connections; this sounds very similar to how HTTPS Everywhere operates. The browser extension tries to upgrade unencrypted resources to encrypted ones when enabled, and it comes with an option to block any traffic that is not encrypted. When enabled, Firefox loads HTTPS sites and resources just like before. When HTTP sites or resources are detected, the browser attempts to upgrade these to HTTPS. The site or resource is loaded if the upgraded worked; if not, it is blocked which may result in sites becoming inaccessible or partially loaded. Firefox users who run Firefox 76 or newer can activate the new HTTPS-Only mode in the browser in the following way: Load about:config in the browser's address bar. Confirm that you will be careful. Search for dom.security.https_only_mode using the search field at the top. Set the preference to TRUE to enable HTTPS-only connections in Firefox. Set the preference to FALSE to allow all connections (default). A "Secure Connection Failed" error is displayed by Firefox is a site cannot be upgraded to HTTPS after setting the preference to TRUE in the Firefox preferences. The new HTTPS-Only mode works like HTTPS Everywhere's strict mode as it blocks all insecure connections automatically. Firefox's built-in feature does not support a fallback mode (which HTTPS Everywhere supports). Is this useful? How useful is a HTTPS-only mode on today's Internet? I see some limited applications for it when combined with browser profiles. A user could enable the feature for a profile that is used exclusively for online banking or other sensitive tasks on the Internet that benefit from increased security. While most sites do support HTTPS already, Mozilla's own stats show that about 82% of all Firefox connections use HTTPS, it is quite common that HTTP-only sites or resources are accessed on the Internet. Most Internet users therefor may find the HTTPS-only mode disruptive as it blocks access to certain sites or resources on the Internet. Source: Firefox 76 gets optional HTTPS-only mode (gHacks - Martin Brinkmann)
  4. Microsoft will integrate DNS over HTTPS in Windows 10 Microsoft revealed plans to integrate native support for DNS over HTTPS in the company's Windows 10 operating system in November 2019. The announcement was made on Microsoft's Networking blog on November 17, 2019. DNS over HTTPS is designed to improve privacy, security and the reliability by encrypting DNS queries that are handled in plaintext currently. DNS over HTTPS has been on the rise lately. Mozilla, Google, Opera as as well as several public DNS providers announced support for the standard. Support in programs, e.g. a web browser, means that the DNS queries that originate from that program are encrypted. Other queries, e.g. from another browser that does not support DNS over HTTPS or is configured not to use it, won't benefit from that integration however. Microsoft's announcement brings DNS over HTTPS support to the Windows operating system. The company plans to introduce it to preview builds of Windows 10 in the future before it releases it in a final version of the operating system. Microsoft plans to follow Google's implementation, at least initially. Google revealed some time ago that it will roll out DNS over HTTPS in Chrome, but only on systems that use a DNS service that supports DNS over HTTPS. In other words: Google won't alter the DNS provider of the system. Mozilla and Opera decided to pick a provider, at least initially, and that means that the local DNS provider may be overridden in the browser. Microsoft notes that it won't be making changes to the DNS server configuration of the Windows machine. Administrators (and users) are in control when it comes to the selection of the DNS provider on Windows and the introduction of support for DNS over HTTPS on Windows won't change that. The change may benefit users without them knowing about it. If a system is configured to use a DNS provider that supports DNS over HTTPS, that system will automatically use the new standard so that DNS data is encrypted. The company plans to introduce "more privacy-friendly ways" for its customers to discover DNS settings in Windows and raise awareness for DNS over HTTPS in the operating system. Microsoft revealed four guiding principles for the implementation: Windows DNS needs to be as private and functional as possible by default without the need for user or admin configuration because Windows DNS traffic represents a snapshot of the user’s browsing history. Privacy-minded Windows users and administrators need to be guided to DNS settings even if they don't know what DNS is yet. Windows users and administrators need to be able to improve their DNS configuration with as few simple actions as possible. Windows users and administrators need to explicitly allow fallback from encrypted DNS once configured. Closing words Microsoft did not reveal a schedule for the integration but it is clear that it will land in a future Insider build for Windows 10 first. Integration in Windows -- and other client operating systems -- makes more sense than integrating the functionality into individual programs. Users who want to use DNS over HTTPS may simply pick a DNS provider that supports it to enable the feature for all applications that run on the system. Source: Microsoft will integrate DNS over HTTPS in Windows 10 (gHacks - Martin Brinkmann)
  5. Google plans to test DNS over HTTPS in Chrome 78 Google revealed plans to test the company's implementation of DNS over HTTPS (DoH) in Chrome 78. DNS over HTTPS aims to improve security and privacy of DNS requests by utilizing HTTPS. The current stable version of Chrome is 77 released on September 10, 2019. Google notes that DoH prevents other WiFi users from seeing visited websites; common attacks such as spoofing or pharming could potentially be prevented by using DoH. Google decided to test the DoH implementation in a different way than Mozilla. Mozilla selected Cloudflare as its partner in the testing phase and will use Cloudflare as the default provider when it rolls out the feature to US users in late September 2019. Firefox users have options to change the DNS over HTTPS provider or turn off the feature entirely in the browser. Google's DNS over HTTPS plan Google picked a different route for the test. The company decided to test the implementation using multiple DoH providers. The company could have used its own DoH service for the tests but decided to select multiple providers instead. Tests will upgrade Chrome installations to use DoH if the DNS service that is used on the system supports DoH. Google circumnavigates any criticism in regards to privacy that Mozilla faced when it announced the partnership with Cloudflare. Google selected the cooperating providers for "their strong stance on security and privacy" and "readiness of their DoH services" and agreement to participate in the test. The following providers were picked by the company: Cleanbrowsing Cloudflare DNS.SB Google OpenDNS Quad9 If Chrome runs on a system that uses one of these services for DNS, it will start using DoH instead when Chrome 78 launches. The experiment will run on all platforms for a fraction of Chrome users with the exception of Chrome on Linux and iOS. Chrome will revert to the regular DNS service in the case of errors. Most managed Chrome deployments will be excluded from the experiment, and Google plans to provide details on DoH policies on the company's Chrome Enterprise blog before release to provide administrators with information on configuring those. Chrome users may use the flag chrome://flags/#dns-over-http to opt in or out of the experiment. The flag is not integrated in any version of the Chrome browser yet. Secure DNS lookups Enables DNS over HTTPS. When this feature is enabled, your browser may try to use a secure HTTPS connection to look up the addresses of websites and other web resources. – Mac, Windows, Chrome OS, Android Closing Words Most Chromium-based browsers and Firefox will start to use DNS over HTTPS in the near future. Firefox provides options to disable the feature and Chrome comes with an experimental flag that offers the same. Experimental flags may be removed at one point in the future however and it is unclear at this point whether Google plans to add a switch to Chrome's preference to enable or disable the feature. Source: Google plans to test DNS over HTTPS in Chrome 78 (gHacks - Martin Brinkmann)
  6. Mozilla plans to roll out DNS over HTTPS to US users in late September 2019 Starting in late September 2019, DNS over HTTPS (DoH) is going to be rolled out to Firefox users in the United States. DNS over HTTPS encrypts DNS requests to improve security and privacy of these requests. Most DNS requests happen in the open currently; anyone listening to the traffic gets records of site and IP addresses that were looked up while using an Internet connection among other things. DoH encrypts the traffic and while that looks good on first glance, it needs to be noted that TLS still gives away the destination in plaintext. One example: Internet providers may block certain DNS requests, e.g. when they have received a court order to block certain resources on the Internet. It is not the best method to prevent people from accessing a site on the Internet but it is used nevertheless. DoH is excellent against censorship that uses DNS manipulation. Tip: check out our detailed guide on configuring DNS over HTTPS in Firefox. Mozilla started to look into the implementation of DoH in Firefox in 2018. The organization ran a controversial Shield study in 2018 to gather data that it needed for the planned implementation of the feature. The study was controversial because Mozilla used the third-party Cloudflare as the DNS over HTTPS service which meant that all user traffic flowed through the Cloudflare network. Mozilla revealed in April 2019 that its plan to enable DoH in Firefox had not changed. The organization created a list of policies that DoH providers had to conform to if they wanted their service to be integrated in Firefox. In "What's next in making encrypted DNS-over-HTTPS the Default", Mozilla confirmed that it would begin to enable DoH in Firefox starting in late September 2019. The feature will be enabled for some users from the United States and Mozilla plans to monitor the implementation before DoH is rolled out to a larger part of the user base and eventually all users from the United States. We plan to gradually roll out DoH in the USA starting in late September. Our plan is to start slowly enabling DoH for a small percentage of users while monitoring for any issues before enabling for a larger audience. If this goes well, we will let you know when we’re ready for 100% deployment. While DNS over HTTPS will be the default for the majority of Firefox installations in the United States, it won't be enabled for some configurations: If parental controls are used, DoH won't be enabled provided that Mozilla detects the use correctly. Enterprise configurations are respected as well and DoH is disabled unless "explicitly enabled by enterprise configuration". Fall back option if DNS issues or split horizon configuration cause lookup failures. Network administrations may configure their networks in the following way to highlight to Firefox that the network is unsuitable for DoH usage: DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver. How to block DNS over HTTPS You have two options when it comes to DoH in Firefox. You can change the default provider -- Cloudflare is the default -- to another provider (for whatever reason) or block the entire feature so that it won't be used. If you don't want to use it, set the value of network.trr.mode to 0 5 on about:config. Source: Mozilla plans to roll out DNS over HTTPS to US users in late September 2019 (gHacks - Martin Brinkmann)
  7. Mozilla revamps Firefox's HTTPS address bar information Mozilla plans to make changes to the information that the organization's Firefox browser displays in its address bar when it connects to sites. Firefox displays an i-icon and a lock symbol currently when connecting to sites. The i-icon displays information about the security of the connection, content blocking, and permissions, the lock icon indicates the security state of the connection visually. A green lock indicates a secure connection and if a site has an Extended Validation certificate, the name of the company is displayed in the address bar as well. Mozilla plans to make changes to the information that is displayed in the browser's address bar that all Firefox users need to be aware of. One of the core changes removes the i-icon from the Firefox address bar, another the Extended Validation certificate name, a third displays a crossed out lock icon for all HTTP sites, and a fourth changes the colour of the lock for HTTPS sites from green to gray. Why are browser makers making these changes? Most Internet traffic happens over HTTPS; latest Firefox statistics show that more than 79% of global pageloads happen using HTTPS and that it is already at more than 87% for users in the United States. The shield icon was introduced to indicate to users that the connection to the site uses HTTPS and to give users options to look up certificate information. It made sense to indicate that to users back when only a fraction of sites used HTTPS. With more and more connections using HTTPS, browser makers like Mozilla or Google decided that it was time to evaluate what is displayed to users in the address bar. Google revealed plans in 2018 to remove Secure and HTTPS indicators from the Chrome browser; Chrome 76, released in August 2019, does not display HTTPS or WWW anymore in the address bar by default. Mozilla launched changes in Firefox in 2018, hidden behind a flag, to add a new "not secure" indicator to HTTP sites in Firefox. Google and Mozilla plan to remove information that indicate that a site's connection is secure. It makes some sense, if you think about it, considering that most connections are secure on today's Internet. Instead of highlighting that a connection is secure, browsers will highlight if a connection is not secure instead. The changes are not without controversy though. For more than two decades, Internet users were told that they needed to verify the security of sites by looking at the lock symbol in the browser's address bar. Mozilla does not remove the lock icon entirely in Firefox 70 and the organization won't touch the protocol in the address bar either at this point; that is better than what Google has already implemented in recent versions of Chrome. The following changes will land in Firefox 70: Firefox won't display the i-icon anymore in the address bar. Firefox won't display the owner of Extended Verification certificates anymore in the address bar. A shield icon is displayed that lists protection information. The lock icon is still displayed, it displays certificate and permission information and controls. HTTPS sites feature a gray lock icon. All sites that use HTTP will be shown with a crossed out shield icon (previously only HTTP sites with login forms). Mozilla aims to launch these changes in Firefox 70. The browser is scheduled for a release on October 23, 2019. Firefox users may add a "not secure" indicator to the browser's address bar. Mozilla, just like Google, plans to display it for sites that use HTTP. The additional indicator needs to be enabled separately at the time of writing, it won't launch in Firefox 70. Load about:config in the Firefox address bar. Search for security.identityblock.show_extended_validation. Set the preference to TRUE to display the name of the owner of Extended Validation certificates in Firefox's address bar, or set it to FALSE to hide it. The new gray icon for HTTPS sites can be toggled as well in the advanced configuration: On about:config, search for security.secure_connection_icon_colour_gray Set the value to TRUE to display a gray icon for HTTPS sites, or set it to FALSE to return to the status quo. Source: Mozilla revamps Firefox's HTTPS address bar information (gHacks - Martin Brinkmann)
  8. Cloudflare aims to make HTTPS certificates safe from BGP hijacking attacks Free service prevents BGP hijackers from fraudulently obtaining browser-trusted certs. Enlarge nternet1.jpg by Rock1997 modified. Content delivery network Cloudflare is introducing a free service designed to make it harder for browser-trusted HTTPS certificates to fall into the hands of bad guys who exploit Internet weaknesses at the time the certificates are issued. The attacks were described in a paper published last year titled Bamboozling Certificate Authorities with BGP. In it, researchers from Princeton University warned that attackers could manipulate the Internet’s border gateway protocol to obtain certificates for domains the attackers had no control over. Browser-trusted certificate authorities are required to use a process known as domain control validation to verify that a person requesting a certificate for a given domain is the legitimate owner. It requires the requesting party to do one of three things: create a domain name system resource record with a specific text string; upload a document with a specific text string to a Web server using the domain; prove receipt of the email address containing a text string sent to the administrative contact for the domain The Princeton researchers demonstrated that this validation process can be bypassed by BGP attacks. Before applying for a certificate to a targeted domain, an adversary can update the Internet’s BGP routing tables to hijack traffic destined for the domain. Then, when a CA checks the DNS record or visits a URL, the CA's query goes to an attacker-controlled server rather than the legitimate server of the domain operator. When the attacker is able to produce the text string designated by the CA, that is considered proof of domain ownership and the CA issues a certificate to the wrong party. Reining it in But these attacks come with limitations. BGP attacks usually hijack only a portion of a domain’s incoming traffic, rather than all of it. As a result, computers in one part of the world will be directed to the attacker’s imposter server, while computers elsewhere will still reach the legitimate server. Cloudflare, with more than 175 datacenters worldwide, is unveiling a new service called multipath domain control validation that’s designed to exploit this limitation of BGP hijacking. As its name suggests, it performs the validation process from multiple origins that follow different Internet paths to the domain. Unless the results from multiple queries are identical, the validation will fail. “We’re going to be leveraging Cloudflare’s global network to perform this domain check, whether it’s DNS or HTTP, from various vantage points that are connected through various networks,” Nick Sullivan, head of cryptography at Cloudflare, told Ars. “If you’re hijacked, [the fraudulent data] only applies to a subset of the requests.” Agents and orchestrators Cloudflare will be making a programming interface available for free to all certificate authorities. The multipath check for domain control validation consists of two services: agents that perform domain validation out of a specific datacenter, and a domain validation “orchestrator” that handles multipath requests from CAs and dispatches them to a subset of agents. When a CA wants to ensure a domain validation hasn’t been intercepted, it can send a request to the Cloudflare API that specifies the type of check it wants. The orchestrator then forwards a request to more than 20 randomly selected agents in different datacenters. Each agent performs the domain validation request and forwards the result to the orchestrator, which aggregates what each agent observed and returns the results to the CA. Sullivan said Cloudflare has designed the new service to be an effective measure against another potential domain validation attack that spoofs IP addresses in DNS requests that use the user datagram protocol (UDP). Because the IP address of the computer making the request can be spoofed, an attacker can make a request to a targeted domain appear to come from a CA. Then, by manipulating a maximum fragment size setting, the attacker can receive a second identical response. The new Cloudflare API prevents these DNS spoofing attacks because it sends queries from multiple locations that can’t be predicted by the attacker, Sullivan said. In a message, he wrote: Multipath DCV was designed for and is primarily effective against on-path attacks. An additional feature that we built into the service that helps protect against off-path attackers is DNS query source IP randomization. By making the source IP unpredictable to the attacker, it becomes more challenging to spoof the second fragment of the forged DNS response to the DCV validation agent. Sullivan said Cloudflare is offering the service for free because the company believes that attacks on the certificate authority system harms the security of the entire Internet. He said he expects the use of multipath domain validation to become standard practice, particularly if it’s offered by other large networks. Eventually, he said, it may be mandated by the CA/browser forum, which sets industry guidelines for the issuance of TLS certificates. “I’m a little surprised this hasn’t happened yet,” Sullivan said. “We’re hoping that this announcement and this product helps spur the CA/Browser forum to adopt and require this more robust multiperspective validation for certificate authorities. It truly is a risk that hasn’t been exploited yet, and it’s just a matter of time.” Source: Cloudflare aims to make HTTPS certificates safe from BGP hijacking attacks (Ars Technica)
  9. Maybe you were once advised to “look for the padlock” as a means of telling legitimate e-commerce sites from phishing or malware traps. Unfortunately, this has never been more useless advice. New research indicates that half of all phishing scams are now hosted on Web sites whose Internet address includes the padlock and begins with “https://”. A live Paypal phishing site that uses https:// (has the green padlock). Recent data from anti-phishing company PhishLabs shows that 49 percent of all phishing sites in the third quarter of 2018 bore the padlock security icon next to the phishing site domain name as displayed in a browser address bar. That’s up from 25 percent just one year ago, and from 35 percent in the second quarter of 2018. This alarming shift is notable because a majority of Internet users have taken the age-old “look for the lock” advice to heart, and still associate the lock icon with legitimate sites. A PhishLabs survey conducted last year found more than 80% of respondents believed the green lock indicated a website was either legitimate and/or safe. In reality, the https:// part of the address (also called “Secure Sockets Layer” or SSL) merely signifies the data being transmitted back and forth between your browser and the site is encrypted and can’t be read by third parties. The presence of the padlock does not mean the site is legitimate, nor is it any proof the site has been security-hardened against intrusion from hackers. A live Facebook phish that uses SSL (has the green padlock). Most of the battle to combat cybercrime involves defenders responding to offensive moves made by attackers. But the rapidly increasing adoption of SSL by phishers is a good example in which fraudsters are taking their cue from legitimate sites. “PhishLabs believes that this can be attributed to both the continued use of SSL certificates by phishers who register their own domain names and create certificates for them, as well as a general increase in SSL due to the Google Chrome browser now displaying ‘Not secure’ for web sites that do not use SSL,” said John LaCour, chief technology officer for the company. “The bottom line is that the presence or lack of SSL doesn’t tell you anything about a site’s legitimacy.” The major Web browser makers work with a number of security organizations to index and block new phishing sites, often serving bright red warning pages that flag the page of a phishing scam and seek to discourage people from visiting the sites. But not all phishing scams get flagged so quickly. I spent a few minutes browsing phishtank.com for phishing sites that use SSL, and found this cleverly crafted page that attempts to phish credentials from users of Bibox, a cryptocurrency exchange. Click the image below and see if you can spot what’s going on with this Web address: This live phish targets users of cryptocurrency exchange Bibox. Look carefully at the URL in the address bar, and you’ll notice a squiggly mark over the “i” in Bibox. This is an internationalized domain name, and the real address is https://www.xn--bbox-vw5a[.]com/login Load the live phishing page at https://www.xn--bbox-vw5a[.]com/login (that link has been hobbled on purpose) in Google Chrome and you’ll get a red “Deceptive Site Ahead” warning. Load the address above — known as “punycode” — in Mozilla Firefox and the page renders just fine, at least as of this writing. This phishing site takes advantage of internationalized domain names (IDNs) to introduce visual confusion. In this case, the “i” in Bibox.com is rendered as the Vietnamese character “ỉ,” which is extremely difficult to distinguish in a URL address bar. As KrebsOnSecurity noted in March, while Chrome, Safari and recent versions of Microsoft’s Internet Explorer and Edge browsers all render IDNs in their clunky punycode state, Firefox will happily convert the code to the look-alike domain as displayed in the address bar. If you’re a Firefox (or Tor) user and would like Firefox to always render IDNs as their punycode equivalent when displayed in the browser address bar, type “about:config” without the quotes into a Firefox address bar. Then in the “search:” box type “punycode,” and you should see one or two options there. The one you want is called “network.IDN_show_punycode.” By default, it is set to “false”; double-clicking that entry should change that setting to “true. Source
  10. Bon anniversaire, Let’s Encrypt! The free-to-use nonprofit was founded in 2014 in part by the Electronic Frontier Foundation and is backed by Akamai, Google, Facebook, Mozilla and more. Three years ago Friday, it issued its first certificate. Since then, the numbers have exploded. To date, more than 380 million certificates have been issued on 129 million unique domains. That also makes it the largest certificate issuer in the world, by far. Now, 75 percent of all Firefox traffic is HTTPS, according to public Firefox data — in part thanks to Let’s Encrypt. That’s a massive increase from when it was founded, where only 38 percent of website page loads were served over an HTTPS encrypted connection. “Change at that speed and scale is incredible,” a spokesperson told TechCrunch. “Let’s Encrypt isn’t solely responsible for this change, but we certainly catalyzed it.” HTTPS is what keeps the pipes of the web secure. Every time your browser lights up in green or flashes a padlock, it’s a TLS certificate encrypting the connection between your computer and the website, ensuring nobody can intercept and steal your data or modify the website. But for years, the certificate market was broken, expensive and difficult to navigate. In an effort to “encrypt the web,” the EFF and others banded together to bring free TLS certificates to the masses. That means bloggers, single-page websites and startups alike can get an easy-to-install certificate for free — even news sites like TechCrunch rely on Let’s Encrypt for a secure connection. Security experts and encryption advocates Scott Helme and Troy Hunt last month found that more than half of the top million websites by traffic are on HTTPS. And as it’s grown, the certificate issuer has become trusted by the major players — including Apple, Google, Microsoft, Oracle and more. A fully encrypted web is still a ways off. But with close to a million Let’s Encrypt certificates issued each day, it looks more within reach than ever. Source
  11. What is this?# I've been writing about Google's efforts to deprecate HTTP, the protocol of the web. This is a summary of why I am opposed to it. DW Their pitch# Advocates of deprecating HTTP make three main points: Something bad could happen to my pages in transit from a server to the user's web browser. It's not hard to convert to HTTPS and it doesn't cost a lot. Google is going to warn people about my site being "not secure." So if I don't want people to be scared away, I should just do what they want me to do. Why this is bad# The web is an open platform, not a corporate platform. It is defined by its stability. 25-plus years and it's still going strong. Google is a guest on the web, as we all are. Guests don't make the rules. Why this is bad, practically speaking# A lot of the web consists of archives. Files put in places that no one maintains. They just work. There's no one there to do the work that Google wants all sites to do. And some people have large numbers of domains and sub-domains hosted on all kinds of software Google never thought about. Places where the work required to convert wouldn't be justified by the possible benefit. The reason there's so much diversity is that the web is an open thing, it was never owned. The web is a miracle# Google has spent a lot of effort to convince you that HTTP is not good. Let me have the floor for a moment to tell you why HTTP is the best thing ever. Its simplicity is what made the web work. It created an explosion of new applications. It may be hard to believe that there was a time when Amazon, Netflix, Facebook, Gmail, Twitter etc didn't exist. That was because the networking standards prior to the web were complicated and not well documented. The explosion happened because the web is simple. Where earlier protocols were hard to build on, the web is easy. I don't think the explosion is over. I want to make it easier and easier for people to run their own web servers. Google is doing what the programming priesthood always does, building the barrier to entry higher, making things more complicated, giving themselves an exclusive. This means only super nerds will be able to put up sites. And we will lose a lot of sites that were quickly posted on a whim, over the 25 years the web has existed, by people that didn't fully understand what they were doing. That's also the glory of the web. Fumbling around in the dark actually gets you somewhere. In worlds created by corporate programmers, it's often impossible to find your way around, by design. The web is a social agreement not to break things. It's served us for 25 years. I don't want to give it up because a bunch of nerds at Google think they know best. The web is like the Grand Canyon. It's a big natural thing, a resource, an inspiration, and like the canyon it deserves our protection. It's a place of experimentation and learning. It's also useful for big corporate websites like Google. All views of the web are important, especially ones that big companies don't understand or respect. It's how progress happens in technology. Keeping the web running simple is as important as net neutrality. They believe they have the power# Google makes a popular browser and is a tech industry leader. They can, they believe, encircle the web, and at first warn users as they access HTTP content. Very likely they will do more, requiring the user to consent to open a page, and then to block the pages outright. It's dishonest# Many of the sites they will label as "not secure" don't ask the user for any information. Of course users won't understand that. Many will take the warning seriously and hit the Back button, having no idea why they're doing it. Of course Google knows this. It's the kind of nasty political tactic we expect from corrupt political leaders, not leading tech companies. Sleight of hand# They tell us to worry about man-in-the-middle attacks that might modify content, but fail to mention that they can do it in the browser, even if you use a "secure" protocol. They are the one entity you must trust above all. No way around it. They cite the wrong stats# When they say some percentage of web traffic is HTTPS, that doesn't measure the scope of the problem. A lot of HTTP-served sites get very few hits, yet still have valuable ideas and must be preserved. It will destroy the web's history# If Google succeeds, it will make a lot of the web's history inaccessible. People put stuff on the web precisely so it would be preserved over time. That's why it's important that no one has the power to change what the web is. It's like a massive book burning, at a much bigger scale than ever done before. If HTTPS is such a great idea...# Why force people to do it? This suggests that the main benefit is for Google, not for people who own the content. If it were such a pressing problem we'd do it because we want to, not because we're being forced to. The web isn't safe# Finally, what is the value in being safe? Twitter and Facebook are like AOL in the old pre-web days. They are run by companies who are committed to provide a safe experience. They make tradeoffs for that. Limited linking. No styles. Character limits. Blocking, muting, reporting, norms. Etc etc. Think of them as Disney-like experiences. The web is not safe. That is correct. We don't want every place to be safe. So people can be wild and experiment and try out new ideas. It's why the web has been the proving ground for so much incredible stuff over its history. Lots of things aren't safe. Crossing the street. Bike riding in Manhattan. Falling in love. We do them anyway. You can't be safe all the time. Life itself isn't safe. If Google succeeds in making the web controlled and bland, we'll just have to reinvent the web outside of Google's sphere. Let's save some time, and create the new web out of the web itself. PS: Of course we want parts of the web to be safe. Banking websites, for example. But my blog archive from 2001? Really there's no need for special provisions there. Update: A threatening email from Google# On June 20, 2018, I got an email from Google, as the owner of scripting.com. According to the email I should "migrate to HTTPS to avoid triggering the new warning on your site and to help protect users' data." It's a blog. I don't ask for any user data. Google’s not secure message means this: “Google tried to take control of the open web and this site said no.” Last update: Tuesday June 26, 2018; 2:11 PM GMT+0200. Source
  12. 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 >
  13. 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
  14. Hi all, I recently have an issue while using Chrome browser, Google.com doesn't load in Chrome, other sites work fine!, it's not a DNS issue because everything is working fine in Firefox, can someone suggest sth?, thanks in advance Screenshot
×
×
  • Create New...