This just in via email from email@example.com. More information is available here: https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811
Cloud provider vulnerability causes Let’s Encrypt to disable SNI domain validation
A major issue with some cloud providers allowed the unauthorized issuance of Let’s Encrypt certificates. Although the issue clearly lies with the cloud providers, Let’s Encrypt nevertheless has decided to disable the corresponding validation method.
Frans Rosén discovered that he could use the SNI validation method from the ACME protocol (https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/) to issue certificates for domains hosted on certain cloud providers. He explicitly mentions Heroku and Amazon CloudFront.
TL;DR: I was able to issue SSL certificates I was not supposed to be able to. AWS CloudFront and Heroku were among the affected. The issue was in the specification of ACME TLS-SNI-01 in combination with shared hosting providers. To be clear, Let’s Encrypt only followed the specification, they did nothing wrong here. Quite the opposite I would say.
The core of the issue is that these providers allow users to upload certificates that the system will serve automatically to TLS requests with the corresponding server name. The ACME SNI validation method uses temporary certificates that end with .acme.invalid.
After the issue was reported, Let’s Encrypt almost immediately disabled the TLS-SNI-01 validation method. Let’s Encrypt subsequently decided that, with a few exceptions, it will stay disabled. The newer TLS-SNI-02 method is vulnerable as well. A new TLS-SNI-03 method that considers this problem is being developed, but for the time being users should switch to either the HTTP or the DNS validation method.
Security never relies on some algorithm, but on the user comprehending the principles and acting sanely. Usually there is a chain of security and every link must be kept secure on its own, for the whole concept to work. Therefore every encryption method has some immanent weaknesses which once met, define a method as considerably secure. But then there is the user…
‘Regards to Bill Hartman and Brietta (Hartman) Williams of Hartman Insurance Services for the assist with our ObamaCare insurance on Healthcare.gov. The additional inside knowledge of how the site really works is most beneficial in satisfying the government mandate to purchase health insurance.
Tomorrow, Monday December 15, 2014, is the last day on which Americans can buy insurance to start in January 2015. Hartman Insurance Services has been around for over 30 years, and delivers premium service at affordable prices. We recommend Hartman Insurance Services for all your health insurance needs.
Contact them at:
215 Airport North Office Park
Fort Wayne, In 46825
FaceBook page: https://www.facebook.com/HartmanInsuranceServices?pnref=story
Google G+: https://plus.google.com/+BillHartman/posts
Whether you are looking for Major Medical, Federal Market Place Certified help, Medicare Supplements, Medicare Advantage, or Prescription Drug Plans, Hartman Insurance Services can help you.
Using State of the Art websites, they will show you how to determine the most appropriate plan available for your situation.
With 30+ years of service in the Indiana and Ohio market place, they continue to educate themselves on the products available. We highly recommend them.
Majorly useful http://davidwalsh.name/download-attribute
download attribute on a link…
<!-- will download as "expenses.pdf" -->
<a href="/files/adlafjlxjewfasd89asd8f.pdf" download="expenses.pdf">Download Your Expense Report</a>
…and when the user clicks the link, the
download attribute appears in the save dialog instead of the garbled mess that was there before. In this case, the file will be downloaded as
download attribute also triggers a force download, something that I used to do on the server side with PHP.
Thank-you for that post!
More good information on this new attribute can be found here
Clicking a link in email is supposed to open the browser, but after a fresh install of Ubuntu Mint/MATE Thunderbird with Chromium-Browser does not open links at all. You are forced to copy the link, change to the browser, then paste the link to open it.
This actually worked:
In Thunderbird 11.0.1, it is simple, yet not intuitive:
- Go to Preferences (Menu Edit → Preferences).
- Click on the Attachments tab.
- In the Content Type and Action section set HTTPS, HTTP, and FTP to Use google-chrome (or other desired browser).
The other suggestions on the page did not work.