Tag Archives: Mozilla

ACME Support in Apache HTTP Server Project

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org//2017/10/17/acme-support-in-apache-httpd.html

We’re excited that support for getting and managing TLS certificates via the ACME protocol is coming to the Apache HTTP Server Project (httpd). ACME is the protocol used by Let’s Encrypt, and hopefully other Certificate Authorities in the future. We anticipate this feature will significantly aid the adoption of HTTPS for new and existing websites.

We created Let’s Encrypt in order to make getting and managing TLS certificates as simple as possible. For Let’s Encrypt subscribers, this usually means obtaining an ACME client and executing some simple commands. Ultimately though, we’d like for most Let’s Encrypt subscribers to have ACME clients built in to their server software so that obtaining an additional piece of software is not necessary. The less work people have to do to deploy HTTPS the better!

ACME support being built in to one of the world’s most popular Web servers, Apache httpd, is great because it means that deploying HTTPS will be even easier for millions of websites. It’s a huge step towards delivering the ideal certificate issuance and management experience to as many people as possible.

The Apache httpd ACME module is called mod_md. It’s currently in the development version of httpd and a plan is being formulated to backport it to an httpd 2.4.x stable release. The mod_md code is also available on GitHub.

It’s also worth mentioning that the development version of Apache httpd now includes support for an SSLPolicy directive. Properly configuring TLS has traditionally involved making a large number of complex choices. With the SSLPolicy directive, admins simply select a modern, intermediate, or old TLS configuration, and sensible choices will be made for them.

Development of mod_md and the SSLPolicy directive has been funded by Mozilla and carried out primarily by Stefan Eissing of greenbytes. Thank you Mozilla and Stefan!

Let’s Encrypt is currently providing certificates for more than 55 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let’s Encrypt even easier. If you’re as excited about the potential for a 100% HTTPS Web as we are, please consider getting involved, making a donation, or sponsoring Let’s Encrypt.

[$] The trouble with text-only email

Post Syndicated from corbet original https://lwn.net/Articles/735973/rss

Mozilla’s manifesto commits
the organization to a number of principles, including support for
individual privacy and an individual’s right to control how they experience
the Internet. As a result, when Mozilla recently stated its intent to
remove the “text only” option from its mailing lists — for the purpose of
tracking whether recipients are reading its emails — the reaction was, to
put it lightly, not entirely positive. The text-only option has been
saved, but the motivation behind this change is indicative of the
challenges facing independent senders of email.

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/735368/rss

Security updates have been issued by CentOS (dnsmasq), Debian (dnsmasq and git), Fedora (ejabberd, firefox, mingw-LibRaw, openvpn, and perl), openSUSE (dnsmasq, git, Mozilla Firefox and NSS, and otrs), Oracle (dnsmasq), Red Hat (dnsmasq), Scientific Linux (dnsmasq), Slackware (dnsmasq), SUSE (dnsmasq), and Ubuntu (dnsmasq, firefox, libidn, and poppler).

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/735121/rss

Security updates have been issued by Arch Linux (ffmpeg2.8, nvidia, and openvpn), Fedora (git, mercurial, moodle, php-horde-Horde-Image, poppler, and pure-ftpd), openSUSE (fmpeg and vlc), Oracle (firefox, kernel, and nss), Red Hat (firefox and nss), Slackware (mozilla), and SUSE (firefox).

All Systems Go! 2017 Schedule Published

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/all-systems-go-2017-schedule-published.html

The All Systems Go! 2017 schedule has been published!

I am happy to announce that we have published the All Systems Go! 2017 schedule!
We are very happy with the large number and the quality of the
submissions we got, and the resulting schedule is exceptionally
strong.

Without further ado:

Here’s the schedule for the first day (Saturday, 21st of October).

And here’s the schedule for the second day (Sunday, 22nd of October).

Here are a couple of keywords from the topics of the talks:
1password, azure, bluetooth, build systems,
casync, cgroups, cilium, cockpit, containers,
ebpf, flatpak, habitat, IoT, kubernetes,
landlock, meson, OCI, rkt, rust, secureboot,
skydive, systemd, testing, tor, varlink,
virtualization, wifi, and more.

Our speakers are from all across the industry: Chef CoreOS, Covalent,
Facebook, Google, Intel, Kinvolk, Microsoft, Mozilla, Pantheon,
Pengutronix, Red Hat, SUSE and more.

For further information about All Systems Go! visit our conference web site.

Make sure to buy your ticket for All Systems Go! 2017 now! A limited
number of tickets are left at this point, so make sure you get yours
before we are all sold out! Find all details here.

See you in Berlin!

Firefox takes a Quantum leap forward with new developer edition (ars technica)

Post Syndicated from ris original https://lwn.net/Articles/734831/rss

Ars technica takes
a look
at the Firefox 57 developer edition. “More important, but less immediately visible, is that Firefox 57 has received a ton of performance enhancement. Project Quantum has several strands to it: Mozilla has developed a new CSS engine, Stylo, that parses CSS files, applies the styling rules to elements on the page, and calculates object sizes and positions. There is also a new rendering engine, WebRender, that uses the GPU to draw the (styled) elements of the page. Compositor combines the individual rendered elements and builds them into a complete page, while Quantum DOM changes how JavaScript runs, especially in background tabs. As well as this new development, there’s a final part, Quantum Flow, which has focused on fixing bugs and adding optimizations to those parts of the browser that aren’t being redeveloped.

WebRender is due to arrive in Firefox 59, but the rest of Quantum is part of Firefox 57.”

Vinyl Shelf Finder

Post Syndicated from Janina Ander original https://www.raspberrypi.org/blog/vinyl-shelf-finder/

It is a truth universally acknowledged that a person in possession of a large record collection must be in want of a good shelving system. Valentin Galea has solved this problem by developing the Vinyl Shelf Finder. In this build, a web-based app directs a pan-and-tilt laser to point out your record of choice among your collection.

Vinyl Shelf Finder demo by Valentin Galea

Ta-dah!

Collector’s issues

People love to collect stuff. Stamps; soap bars; Troll dolls; belly button fluff (no, really); if you can think of a tangible item, someone out there in the world is collecting it. Of course, every collector needs to solve two issues — which system to use for cataloguing and sorting their collection, and how to best retrieve items from it. This is where Valentin’s Vinyl Shelf Finder comes in. He says:

My vinyl collection is pretty modest — about 500 records in one vertical shelf and a couple of boxes. This is enough to get cumbersome when I’m searching for specific stuff, so I came up with the idea of a automated laser pointer finder.

The Vinyl Shelf Finder

Valentin keeps an online record of his vinyl collection using Discogs. He entered each LP’s shelf position into the record, and wrote a Node.js app to access the Discogs database. The mobile app has a GUI from which he chooses records based on their name and cover image. To build the hardware, he mounted a Pimoroni Pan-Tilt HAT on a Raspberry Pi, and affixed a laser pointer to the HAT. When he selects a record in the app, the pan-and-tilt laser moves to point out the LP’s location.

Valentin Galea on Twitter

my latest hobby prj: #vinyl finder – with lazers and #raspberrypi #iot and #nodejs – https://t.co/IGGzQDgUFI https://t.co/7YBE3svGyE

Not only does the app help Valentin find records – he has also set it up to collect listening statistics using the Last.fm API. He plans to add more sophisticated statistics, and is looking into how to automate the entry of the shelf positions into his database.

If you’re interested in the Vinyl Shelf Finder, head over to Valentin’s GitHub to learn more, and to find out about updates he is making to this work in progress.

GUI of Valentin Galea's Vinyl Shelf Finder app

 

Vinyl + Pi

We’ve previously blogged about Mike Smith’s kaleidoscopic Recordshelf build — maybe he and Valentin could team up to create the ultimate, beautiful, practical vinyl-shelving system!

If you listen to lots of LP records and would like to learn about digitising them, check out this Pi-powered project from Mozilla HQ. If, on the other hand, you have a vinyl player you never use, why not make amazing art with it by hacking it into a CNC Wood Burner?

Are you a collector of things common or unusual? Could Raspberry Pi technology help make your collection better? Share your ideas with us in the comments!

The post Vinyl Shelf Finder appeared first on Raspberry Pi.

Verified cryptography for Firefox 57

Post Syndicated from corbet original https://lwn.net/Articles/733675/rss

The Mozilla Security Blog announces
that Firefox 57 will benefit from the addition of a formally verified
crypto package.
The first result of this collaboration, an implementation of the
Curve25519 key establishment algorithm (RFC7748), has just landed in
Firefox Nightly. Curve25519 is widely used for key-exchange in TLS, and was
recently standardized by the IETF. As an additional bonus, besides being
formally verified, the HACL* Curve25519 implementation is also almost 20%
faster on 64 bit platforms than the existing NSS implementation (19500
scalar multiplications per second instead of 15100) which represents an
improvement in both security and performance to our users.

Security updates for Thursday

Post Syndicated from corbet original https://lwn.net/Articles/730474/rss

Security updates have been issued by Debian (firefox-esr), Fedora (cacti, community-mysql, and pspp), Mageia (varnish), openSUSE (mariadb, nasm, pspp, and rubygem-rubyzip), Oracle (evince, freeradius, golang, java-1.7.0-openjdk, log4j, NetworkManager and libnl3, pki-core, qemu-kvm, and X.org), Red Hat (flash-plugin), and Slackware (curl and mozilla).

Deploying an NGINX Reverse Proxy Sidecar Container on Amazon ECS

Post Syndicated from Nathan Peck original https://aws.amazon.com/blogs/compute/nginx-reverse-proxy-sidecar-container-on-amazon-ecs/

Reverse proxies are a powerful software architecture primitive for fetching resources from a server on behalf of a client. They serve a number of purposes, from protecting servers from unwanted traffic to offloading some of the heavy lifting of HTTP traffic processing.

This post explains the benefits of a reverse proxy, and explains how to use NGINX and Amazon EC2 Container Service (Amazon ECS) to easily implement and deploy a reverse proxy for your containerized application.

Components

NGINX is a high performance HTTP server that has achieved significant adoption because of its asynchronous event driven architecture. It can serve thousands of concurrent requests with a low memory footprint. This efficiency also makes it ideal as a reverse proxy.

Amazon ECS is a highly scalable, high performance container management service that supports Docker containers. It allows you to run applications easily on a managed cluster of Amazon EC2 instances. Amazon ECS helps you get your application components running on instances according to a specified configuration. It also helps scale out these components across an entire fleet of instances.

Sidecar containers are a common software pattern that has been embraced by engineering organizations. It’s a way to keep server side architecture easier to understand by building with smaller, modular containers that each serve a simple purpose. Just like an application can be powered by multiple microservices, each microservice can also be powered by multiple containers that work together. A sidecar container is simply a way to move part of the core responsibility of a service out into a containerized module that is deployed alongside a core application container.

The following diagram shows how an NGINX reverse proxy sidecar container operates alongside an application server container:

In this architecture, Amazon ECS has deployed two copies of an application stack that is made up of an NGINX reverse proxy side container and an application container. Web traffic from the public goes to an Application Load Balancer, which then distributes the traffic to one of the NGINX reverse proxy sidecars. The NGINX reverse proxy then forwards the request to the application server and returns its response to the client via the load balancer.

Reverse proxy for security

Security is one reason for using a reverse proxy in front of an application container. Any web server that serves resources to the public can expect to receive lots of unwanted traffic every day. Some of this traffic is relatively benign scans by researchers and tools, such as Shodan or nmap:

[18/May/2017:15:10:10 +0000] "GET /YesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScann HTTP/1.1" 404 1389 - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
[18/May/2017:18:19:51 +0000] "GET /clientaccesspolicy.xml HTTP/1.1" 404 322 - Cloud mapping experiment. Contact [email protected]

But other traffic is much more malicious. For example, here is what a web server sees while being scanned by the hacking tool ZmEu, which scans web servers trying to find PHPMyAdmin installations to exploit:

[18/May/2017:16:27:39 +0000] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 391 - ZmEu
[18/May/2017:16:27:39 +0000] "GET /web/phpMyAdmin/scripts/setup.php HTTP/1.1" 404 394 - ZmEu
[18/May/2017:16:27:39 +0000] "GET /xampp/phpmyadmin/scripts/setup.php HTTP/1.1" 404 396 - ZmEu
[18/May/2017:16:27:40 +0000] "GET /apache-default/phpmyadmin/scripts/setup.php HTTP/1.1" 404 405 - ZmEu
[18/May/2017:16:27:40 +0000] "GET /phpMyAdmin-2.10.0.0/scripts/setup.php HTTP/1.1" 404 397 - ZmEu
[18/May/2017:16:27:40 +0000] "GET /mysql/scripts/setup.php HTTP/1.1" 404 386 - ZmEu
[18/May/2017:16:27:41 +0000] "GET /admin/scripts/setup.php HTTP/1.1" 404 386 - ZmEu
[18/May/2017:16:27:41 +0000] "GET /forum/phpmyadmin/scripts/setup.php HTTP/1.1" 404 396 - ZmEu
[18/May/2017:16:27:41 +0000] "GET /typo3/phpmyadmin/scripts/setup.php HTTP/1.1" 404 396 - ZmEu
[18/May/2017:16:27:42 +0000] "GET /phpMyAdmin-2.10.0.1/scripts/setup.php HTTP/1.1" 404 399 - ZmEu
[18/May/2017:16:27:44 +0000] "GET /administrator/components/com_joommyadmin/phpmyadmin/scripts/setup.php HTTP/1.1" 404 418 - ZmEu
[18/May/2017:18:34:45 +0000] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 404 390 - ZmEu
[18/May/2017:16:27:45 +0000] "GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1" 404 401 - ZmEu

In addition, servers can also end up receiving unwanted web traffic that is intended for another server. In a cloud environment, an application may end up reusing an IP address that was formerly connected to another service. It’s common for misconfigured or misbehaving DNS servers to send traffic intended for a different host to an IP address now connected to your server.

It’s the responsibility of anyone running a web server to handle and reject potentially malicious traffic or unwanted traffic. Ideally, the web server can reject this traffic as early as possible, before it actually reaches the core application code. A reverse proxy is one way to provide this layer of protection for an application server. It can be configured to reject these requests before they reach the application server.

Reverse proxy for performance

Another advantage of using a reverse proxy such as NGINX is that it can be configured to offload some heavy lifting from your application container. For example, every HTTP server should support gzip. Whenever a client requests gzip encoding, the server compresses the response before sending it back to the client. This compression saves network bandwidth, which also improves speed for clients who now don’t have to wait as long for a response to fully download.

NGINX can be configured to accept a plaintext response from your application container and gzip encode it before sending it down to the client. This allows your application container to focus 100% of its CPU allotment on running business logic, while NGINX handles the encoding with its efficient gzip implementation.

An application may have security concerns that require SSL termination at the instance level instead of at the load balancer. NGINX can also be configured to terminate SSL before proxying the request to a local application container. Again, this also removes some CPU load from the application container, allowing it to focus on running business logic. It also gives you a cleaner way to patch any SSL vulnerabilities or update SSL certificates by updating the NGINX container without needing to change the application container.

NGINX configuration

Configuring NGINX for both traffic filtering and gzip encoding is shown below:

http {
  # NGINX will handle gzip compression of responses from the app server
  gzip on;
  gzip_proxied any;
  gzip_types text/plain application/json;
  gzip_min_length 1000;
 
  server {
    listen 80;
 
    # NGINX will reject anything not matching /api
    location /api {
      # Reject requests with unsupported HTTP method
      if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|PUT|DELETE)$) {
        return 405;
      }
 
      # Only requests matching the whitelist expectations will
      # get sent to the application server
      proxy_pass http://app:3000;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection 'upgrade';
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_cache_bypass $http_upgrade;
    }
  }
}

The above configuration only accepts traffic that matches the expression /api and has a recognized HTTP method. If the traffic matches, it is forwarded to a local application container accessible at the local hostname app. If the client requested gzip encoding, the plaintext response from that application container is gzip-encoded.

Amazon ECS configuration

Configuring ECS to run this NGINX container as a sidecar is also simple. ECS uses a core primitive called the task definition. Each task definition can include one or more containers, which can be linked to each other:

 {
  "containerDefinitions": [
     {
       "name": "nginx",
       "image": "<NGINX reverse proxy image URL here>",
       "memory": "256",
       "cpu": "256",
       "essential": true,
       "portMappings": [
         {
           "containerPort": "80",
           "protocol": "tcp"
         }
       ],
       "links": [
         "app"
       ]
     },
     {
       "name": "app",
       "image": "<app image URL here>",
       "memory": "256",
       "cpu": "256",
       "essential": true
     }
   ],
   "networkMode": "bridge",
   "family": "application-stack"
}

This task definition causes ECS to start both an NGINX container and an application container on the same instance. Then, the NGINX container is linked to the application container. This allows the NGINX container to send traffic to the application container using the hostname app.

The NGINX container has a port mapping that exposes port 80 on a publically accessible port but the application container does not. This means that the application container is not directly addressable. The only way to send it traffic is to send traffic to the NGINX container, which filters that traffic down. It only forwards to the application container if the traffic passes the whitelisted rules.

Conclusion

Running a sidecar container such as NGINX can bring significant benefits by making it easier to provide protection for application containers. Sidecar containers also improve performance by freeing your application container from various CPU intensive tasks. Amazon ECS makes it easy to run sidecar containers, and automate their deployment across your cluster.

To see the full code for this NGINX sidecar reference, or to try it out yourself, you can check out the open source NGINX reverse proxy reference architecture on GitHub.

– Nathan
 @nathankpeck

EFF: Bassel Khartabil, In Memoriam

Post Syndicated from ris original https://lwn.net/Articles/729644/rss

The Electronic Frontier Foundation reports
that Bassel Khartabil, Syrian open source developer, blogger,
entrepreneur, hackerspace founder, and free culture advocate, was executed
by the Syrian authorities. “Bassel was a central figure in the
global free culture movement, connecting it and promoting it to Syria’s
emerging tech community as it existed before the country was ransacked by
civil war. He co-founded Aiki Lab, Syria’s first hackerspace, in Damascus
in 2010. He was a contributor to Mozilla’s Firefox browser and the Syrian
lead for Creative Commons. His influence went beyond Syria, however: he was
a key attendee at the Middle East’s bloggers’ conferences, and played a
vital role in the negotiations in Doha in 2010 that led to a common
language for discussing fair use and copyright across the Arab-speaking
world.
” (Thanks to Paul Wise)

The end of Flash

Post Syndicated from corbet original https://lwn.net/Articles/728790/rss

The long-awaited end of Flash has come a little closer with this
announcement
from Adobe. “Given this progress, and in
collaboration with several of our technology partners – including Apple,
Facebook, Google, Microsoft and Mozilla – Adobe is planning to end-of-life
Flash. Specifically, we will stop updating and distributing the Flash
Player at the end of 2020 and encourage content creators to migrate any
existing Flash content to these new open formats.

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/725989/rss

Security updates have been issued by Arch Linux (glibc and lib32-glibc), CentOS (glibc and kernel), Debian (eglibc, kernel, and libffi), openSUSE (exim, freeradius-server, libxml2, Mozilla based packages, and xorg-x11-server), Oracle (glibc and kernel), Scientific Linux (glibc and kernel), SUSE (glibc, kernel, and openvpn), and Ubuntu (eglibc, glibc, exim4, libnl3, linux, linux-meta, linux-aws, linux-meta-aws, linux-gke, linux-meta-gke, linux-hwe, linux-meta-hwe, linux-lts-xenial, linux-meta-lts-xenial, linux-meta-raspi2, linux-raspi2, and linux-meta-snapdragon, linux-snapdragon).

[$] The Brave web browser

Post Syndicated from jake original https://lwn.net/Articles/725261/rss

The Brave web browser is a project from
a new company called Brave Software. It was founded by Brendan Eich, who is the
inventor of JavaScript and former developer and CTO at Mozilla; he
hopes to dramatically re-invent the advertising model of the web while
strengthening user anonymity and security. Brave’s value proposition is
that instead of being served advertisements from web sites that use the
revenue to pay their bills, users can opt to directly pay the content
providers of their choosing with cryptocurrency. Also, there is a
recognition of the
utility of targeted advertising, so users have an option of saving a local,
protected profile that can be used anonymously to obtain targeted
advertisements instead of having their online behavior tracked and sold by
a third party.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/725504/rss

Security updates have been issued by Arch Linux (flashplugin, kmail, lib32-flashplugin, and messagelib), CentOS (firefox), Debian (firefox-esr and libsndfile), Fedora (ettercap, gajim, libsndfile, poppler, and webkitgtk4), Mageia (catdoc, ettercap, libcryptopp, libytnef, and tor), Oracle (firefox), Scientific Linux (firefox), Slackware (bind and mozilla), SUSE (jakarta-taglibs-standard), and Ubuntu (firefox).

ACME v2 API Endpoint Coming January 2018

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org//2017/06/14/acme-v2-api.html

Let’s Encrypt will add support for the IETF-standardized ACME v2 protocol in January of 2018. We will be adding a new ACME v2 API endpoint alongside our existing ACME v1 protocol API endpoint. We are not setting an end-of-life date for our ACME v1 API at this time, though we recommend that people move to the ACME v2 endpoint as soon as possible once it’s available. For most subscribers, this will happen automatically via a hosting provider or normal ACME client software update.

The ACME protocol, initially developed by the team behind Let’s Encrypt, is at the very heart of the CA service we provide. It’s the primary way in which we interact with our subscribers so that they can get and manage certificates. The ACME v1 protocol we use today was designed to ensure that our validation, issuance, and management methods are fully automated, consistent, compliant, and secure. In these respects, the current ACME v1 protocol has served us well.

There are three primary reasons why we’re starting a transition to ACME v2.

First, ACME v2 will be an IETF standard, and it’s important to us that we support true standards. While ACME v1 is a well-documented public specification, developed in a relatively open manner by individuals from a number of different organizations (including Mozilla, the Electronic Frontier Foundation, and the University of Michigan), it did not benefit from having been developed within a standards body with a greater diversity of inputs and procedures based on years of experience. It was always our intent for ACME v1 to form the basis for an IETF standardization process.

Second, ACME v2 was designed with additional input from other CAs besides Let’s Encrypt, so it should be easier for other CAs to use. We want a standardized ACME to work for many CAs, and ACME v1, while usable by other CAs, was designed with Let’s Encrypt in particular in mind. ACME v2 should meet more needs.

Third, ACME v2 brings some technical improvements that will allow us to better serve our subscribers going forward.

We are not setting an end-of-life date for the ACME v1 protocol because we don’t yet have enough data to determine when would be an appropriate date. Once we’re confident that we can predict an appropriate end-of-life date for our ACME v1 API endpoint we’ll announce one.

ACME v2 is the result of great work by the ACME IETF working group. In particular, we were happy to see the ACME working group take into account the needs of other organizations that may use ACME in the future. Certificate issuance and management protocols are a critical component of the Web’s trust model, and the Web will be better off if CAs can use a standardized public protocol that has been thoroughly vetted.

We’d like to thank our community, including our sponsors, for making everything we did this past year possible. Please consider getting involved or making a donation. If your company or organization would like to sponsor Let’s Encrypt please email us at [email protected].

Tor Browser 7.0 released

Post Syndicated from ris original https://lwn.net/Articles/724806/rss

The Tor Browser Team has announced the first stable release in the 7.0 series. “This release brings us up to date with Firefox 52 ESR which contains progress in a number of areas:

Most notably we hope having Mozilla’s multiprocess mode (e10s) and content sandbox enabled will be one of the major new features in the Tor Browser 7.0 series, both security- and performance-wise. While we are still working on the sandboxing part for Windows (the e10s part is ready), both Linux and macOS have e10s and content sandboxing enabled by default in Tor Browser 7.0. In addition to that, Linux and macOS users have the option to further harden their Tor Browser setup by using only Unix Domain sockets for communication with tor.”

Try Amazon WorkSpaces at No Charge for Up To 2 Months

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/try-amazon-workspaces-at-no-charge-for-up-to-2-months/

I am a big believer in hands-on experience. Except under very rare circumstances, the posts in my blog are written only after I have used the service in question. If you happened to read I Love My Amazon WorkSpace, you know that Amazon WorkSpaces is one of my most important productivity tools.

I would like to tell you about an opportunity for you to try WorkSpaces on your own at no charge. The new Amazon WorkSpaces Free Tier allows you to launch two Standard bundle WorkSpaces and use them for a total of 40 hours per month, for up to two calendar months. You can choose either the Windows 7 or the Windows 10 Desktop Experience, both powered by Windows Server. Both options include Internet Explorer 11, Mozilla Firefox, 7-Zip, and Amazon WorkDocs with 50 GB of storage.

In order to take advantage of the free tier you must run the WorkSpaces in AutoStop mode, which is selected for you by default. Unused hours expire at the end of the first calendar month and the free tier offer expires at the end of the second calendar month. After that you will be billed at the hourly rate listed on the Amazon WorkSpaces Pricing page.

To get started, follow the steps in the Quick Setup and choose a bundle that is eligible for the free tier:

This offer is available in all AWS Regions where WorkSpaces is available.

Jeff;

Huge Coalition Protests EU Mandatory Piracy Filter Proposals

Post Syndicated from Andy original https://torrentfreak.com/huge-coalition-protests-eu-mandatory-piracy-filter-proposals-170530/

Last September, EU Commission President Jean-Claude Juncker announced plans to modernize copyright law in Europe.

The proposals (pdf) are part of the Digital Single Market reforms, which have been under development for the past several years.

The proposals cover a broad range of copyright-related issues, but one stands out as being particularly controversial. Article 13 requires certain online service providers to become deeply involved in the detection and policing of allegedly infringing copyright works, uploaded to their platforms by users.

Although its effects will likely be more broad, the proposal is targeted at the so-called “value gap” (1,2,3), i.e the notion that platforms like YouTube are able to avoid paying expensive licensing fees (for music in particular) by exploiting the safe harbor protections of the DMCA and similar legislation.

To close this loophole using Article 13, services that provide access to “large amounts” of user-uploaded content would be required to cooperate with rightsholders to prevent infringing works being communicated to the public.

This means that platforms like YouTube would be forced to take measures to ensure that their deals with content providers to distribute official content are protected by aggressive anti-piracy mechanisms.

The legislation would see platforms forced to deploy content-recognition, filtering and blocking mechanisms, to ensure that only non-infringing content is uploaded in the first place, thus limiting the chances that unauthorized copyrighted content will be made available to end users.

Supporters argue that the resulting decrease in availability of infringing content will effectively close the “value gap” but critics see the measures as disproportionate, likely to result in censorship (no provision for fair use), and a restriction of fundamental freedoms. Indeed, there are already warnings that such a system would severely “restrict the way Europeans create, share, and communicate online.”

The proposals have predictably received widespread support from entertainment industry companies across the EU and the United States, but there are now clear signs that the battle lines are being drawn.

On one side are the major recording labels, movie studios, and other producers. On the other, companies and platforms that will suddenly become more liable for infringing content, accompanied by citizens and scholars who feel that freedoms will be restricted.

The latest sign of the scale of opposition to Article 13 manifests itself in an open letter to the European Parliament. Under the Copyright for Creativity (C4C) banner and signed by the EFF, Creative Commons, Wikimedia, Mozilla, EDRi, Open Rights Group plus sixty other organizations, the letter warns that the proposals will cause more problems than they solve.

“The European Commission’s proposal on copyright in the Digital Single Market failed to meet the expectations of European citizens and businesses. Instead of supporting Europeans in the digital economy, it is backward looking,” the groups say.

“We need European lawmakers to oppose the most damaging aspects of the proposal, but also to embrace a more ambitious agenda for positive reform.”

In addition to opposing Article 11 (the proposed Press Publishers’ Right), the groups ask the EU Parliament not to impose private censorship on EU citizens via Article 13.

“The provision on the so-called ‘value gap’ is designed to provoke such legal uncertainty that online services will have no other option than to monitor, filter and block EU citizens’ communications if they want to have any chance of staying in business,” the groups write.

“The Commission’s proposal misrepresents some European Court rulings and seeks to impose contradictory obligations on Member States. This is simply bad regulation.”

Calling for the wholesale removal of Article 13 from the copyright negotiations, the groups argue that the reforms should be handled in the appropriate contexts.

“We strenuously oppose such ill thought through experimentation with intermediary liability, which will hinder innovation and competition and will reduce the opportunities available to all European businesses and citizens,” they add.

C4C concludes by calling on lawmakers to oppose Article 13 while seeking avenues for positive reform.

The full letter can be found here (pdf)

Source: TF, for the latest info on copyright, file-sharing, torrent sites and ANONYMOUS VPN services.