You are here

Shtëpia

Agreguesi i feed

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, August 2017

Planet Ubuntu - Dje, 17/09/2017 - 10:24pd

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In August, about 189 work hours have been dispatched among 12 paid contributors. Their reports are available:

Evolution of the situation

The number of sponsored hours is the same as last month.

The security tracker currently lists 59 packages with a known CVE and the dla-needed.txt file 60. The number of packages with open issues decreased slightly compared to last month but we’re not yet back to the usual situation. The number of CVE to fix per package tends to increase due to the increased usage of fuzzers.

Thanks to our sponsors

New sponsors are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Costales: Píldora snap: Crea una aplicación snap en 5 minutos

Planet Ubuntu - Enj, 14/09/2017 - 7:17md
En sólo 5 minutos vas a empaquetar tu primera aplicación snap. ¡Más fácil, imposible!
¿Aceptas el reto? ;) ¡Adelante!

vídeo tutorial

Basado en la conferencia de Alan Pope y Martin Wimpress de la 2ª Ubucon Europea:

snap! snap! snap!

Ubuntu Podcast from the UK LoCo: S10E28 – Momentous Sparkling Jellyfish - Ubuntu Podcast

Planet Ubuntu - Enj, 14/09/2017 - 5:30md

This week we’ve been adding LED lights to a home studio, we announce the winner of the Entroware Apollo competition, serve up some GUI love and go over your feedback.

It’s Season Ten Episode Twenty-Eight of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

In this week’s show:

Entroware Competition Winner!

Congratulations to Dave Hingley for creating The Ubuntu Guys comic which was scripted in 20 minutes.

All entries

In no particular order here are all the entries

Roger Light

Hollow out the middle of a file with AppHollow from Roger Light's entry to the @Entroware Apollo competition https://t.co/yroZBtBuEK

— Ubuntu Podcast (@ubuntupodcast) September 7, 2017

Neil McPhail

Sorry Neil, it’s 2017 and we still can’t edit tweets!

Ian McPhail created a unique audio composition for the @Entroware Apollo competition. Paean to beans https://t.co/AaIIJM84Jc

— Ubuntu Podcast (@ubuntupodcast) September 8, 2017

Andy Partington

Dynamically update your @digitalocean DNS with Andy Partington's entry to the @Entroware Apollo competition https://t.co/3YCGYGv2Ne

— Ubuntu Podcast (@ubuntupodcast) September 8, 2017

Joe Ressington

Listen to Joe Ressington's musical entry to the @Entroware Apollo competition https://t.co/QuQbOiflNJ

— Ubuntu Podcast (@ubuntupodcast) September 8, 2017

Paul Gault

Check the list once check the list twice and find our who is Naughty or Nice with Paul Gault's entry to the @Entroware Apollo competition. pic.twitter.com/oquL2frlcT

— Ubuntu Podcast (@ubuntupodcast) September 9, 2017

Robert Rijkhoff

Desktop notifications of Ubuntu Podcast episodes with Robert Rijkhoff's entry to the @Entroware Apollo competition https://t.co/753VfOaBMp

— Ubuntu Podcast (@ubuntupodcast) September 9, 2017

Gentleman Punter

Find out the answer to the most pressing question on the Internet at https://t.co/doBTNNbXWi created for the @Entroware Apollo competition

— Ubuntu Podcast (@ubuntupodcast) September 9, 2017

Ivan Pejić

Ubuntu Podcast logo that embeds our theme tune. Submitted to the @Entroware Apollo competition by Ivan Pejić. https://t.co/fLNMWSgMYh

— Ubuntu Podcast (@ubuntupodcast) September 10, 2017

Mattias Wernér

Mattias Wernér sent a Hiaku to the @Entroware Apollo competition: Installing Ubuntu. Quick installation creates hope. Network unreachable.

— Ubuntu Podcast (@ubuntupodcast) September 10, 2017

Masoud Abkenar

Johan Seyfferdt sent his 20 line Linux origin story to the @Entroware Apollo competition https://t.co/5cc58Z7AJ5

— Ubuntu Podcast (@ubuntupodcast) September 11, 2017

Johan Seyfferdt

Command line junkies can edit video in the terminal thanks to Masoud Abkenar's @Entroware Apollo competition entry https://t.co/3usE5Y6iBa

— Ubuntu Podcast (@ubuntupodcast) September 11, 2017

Ovidiu Serban

Send text as tweets using Ovidiu Serbans's entry to the @Entroware Apollo competition entry https://t.co/hdaYYtxK9m

— Ubuntu Podcast (@ubuntupodcast) September 11, 2017

Ryan Warnock

Ryan Warnock wrote a 20 line poem for the @Entroware Apollo competition to express how he feels about recent events. pic.twitter.com/whiPa1StqS

— Ubuntu Podcast (@ubuntupodcast) September 11, 2017

Dave Hingley

Read the (first installment?) of Ubuntu Guys, scripted in 20 mins by Dave Hingley for the @Entroware Apollo competition pic.twitter.com/odisXDh9yz

— Ubuntu Podcast (@ubuntupodcast) September 12, 2017

Ian Phillips

Mmmmmm, beer. Crafted from 20 vector objects by Ian Phillips for the @Entroware Apollo competition. https://t.co/0TMoCc7QF8

— Ubuntu Podcast (@ubuntupodcast) September 12, 2017

Brain Walton

Brian Walton sent a 20 line program for the ZX Spectrum to the @Entroware Apollo competition. Music and pictures! https://t.co/XtaQoCXIEy

— Ubuntu Podcast (@ubuntupodcast) September 12, 2017

Martin Tallosy

A PointCloud of Apollo, made from 20 photos, is what Martin Tallosy's submitted to the @Entroware Apollo competition https://t.co/f8hxakexIQ

— Ubuntu Podcast (@ubuntupodcast) September 13, 2017

Lucy Walton

Lucy Walton drew a portrait of @popey, @marxjohnson and @m_wimpress with just 20 hard drawn lines for the @Entroware Apollo competition pic.twitter.com/bEfCUJzOv2

— Ubuntu Podcast (@ubuntupodcast) September 13, 2017

That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

Costales: Crónica de la 2ª Ubucon Europea

Planet Ubuntu - Mër, 13/09/2017 - 7:58md
6 de Septiembre, Miércoles
¡Por fin! Una nueva Ubucon Europea está a la vuelta de la esquina. Tras la primera de Alemania, toca París. Llegué un par de días antes, pues era más barato el avión en estas fechas tan saturadas de turistas.
Marius Quabeck, Miguel Menéndez y un par de chicos escandinavos (los cuales hicieron una bolera con Arduinos) nos juntamos de manera improvisada para cenar enfrente del museo donde se haría el evento.
super peque!
Tras pizza, cerveza y un montón de conversación, cada mochuelo a su olivo, ya con ganas de entrar en la antesala del evento.

7 de Septiembre, Jueves
A primera hora, nos acercamos Miguel y yo a la Ciudad de las Ciencias y de la Industria, que es el museo donde se desarrolla la Ubucon, para echar una mano a la organización y revisar que todo iba a funcionar como debería en nuestras conferencias.Allí se encontraban muchos de los organizadores (aunque no todos por ser un día laboral). Ayudé a colocar mesas, desempaquetar los ordenadores y montarlos. Casi sin darme cuenta ya era la hora de comer, aunque bueno, con lo temprano que ellos comen... casi que era la hora del vermú :P
ubuntu por doquier :))
Nos acercamos todos a una pizzería, momento en el que se juntaron los grandes Diogo (del equipo portugués), Alan Pope y Martin Wimpress (estos dos últimos muy conocidos por su podcast y Ubuntu MATE). La comida fue agradable e incluso se dilató bastante, para una vez finalizada la sobremesa volver al museo y acabar con los preparativos del día siguiente.
En la tarde, el equipo francés organizó un paseo en barca por el río hasta la Torre Eiffel. Como ya conozco de visitas anteriores la capital de Francia, quedé en el evento hasta la hora de las copas, que eran en un bar alejado del evento, aunque muy peculiar. El bar estaba a la vera del río Sena, era un local muy antiguo, consistente en bóvedas de piedra. Era tan grande que incluso había un concierto en una de las esquinas y no molestaba al resto del bar. También había obras de teatro de manera espontánea. Muy original y único.
foto
Para cenar, salimos en busca de un restaurante de comida rápida, aunque acabamos en una pizzería de los Campos Elíseos, muy cara, pero es lo que hay en esa zona. Me encantó muchísimo la cena, pues me senté enfrente de Alan y Martin y hablamos mucho sobre la distribución.
Ya entrando en la media noche y temerosos de que cerrasen el metro, nos fuimos Miguel y yo al hotel.

Día 1 de la Ubucon, 8 de Septiembre, Viernes
Tras dormir como un lirón, me acerqué bien temprano al evento. El museo de la Ciudad de las Ciencias y de la Industria impresiona por su tamaño desde el exterior. Tras pasar el control de seguridad, bajas al nivel -1 y enfrente de la biblioteca, donde está situado el FabLab, entras en el recinto de la Ubucon.
museo
Nada más entrar, a mano izquierda hay una zona para jugar los niños, ideal para que los padres que quieran asistir puedan desentenderse de sus hijos mientras atienden las conferencias.A mano derecha está un mostrador, para recibir a los visitantes y con muchísimo merchandising a la venta y hay que decir, que ese dinero va directamente a la organización para ayudar en futuros eventos.Si avanzamos unos metros, tenemos a mano derecha ordenadores con Ubuntu para que cualquier visitante pueda probarlo in situ y frente a esos ordenadores, distintas organizaciones. Este año, UBPorts, Open Food Facts, Mozilla y Slimbook.
UBportsSlimbookMozillaZona para niños
Tras pasar esta zona, tenemos la primera sala de conferencias, la más pequeña y frente a ella, una sala de talleres, con unos 20 ordenadores. Si atraviesas esa sala destinada a talleres, llegas al área de install party, por donde pasan decenas de personas con su portátil para instalar Ubuntu.
Al final del evento, está la última de las salas, la más grande.

Olive y Rudy abrieron la Ubucon, contando por qué lo organizaban. Dando entrada a la primera de las charlas, la de Alan Pope sobre snapcraft.
Rudy & Olivemicro tutorial Muchísima audiencia para la charla de Alan
El resto del día, se desarrolla con charlas simultáneas, lo cual es bueno y malo. Bueno, porque si una no te atrae, vas a otra; y malo porque si te gustan ambas, te pierdes una ;)Destacaría en este día las conferencias de Alan Pope, la presentación del proyecto UBports y el curso de programación de Ubuntu Touch por parte de Miguel.
Charla UBports Michal presentando la bolera con Arduino
Yo también puse mi granito de arena con la conferencia "Cómo hacer que triunfe tu proyecto de software libre".El equipo francés preparó hasta el último detalle a conciencia, y ellos mismos preparaban la comida para organizadores y conferenciantes, así no tenías que irte fuera para comer y estabas junto a todos.

Al anochecer, el evento social fue en un bar que disfruté mucho. Se juntó el resto de la comitiva portuguesa con Tiago y Lucía, y como no había para comer en el bar, hicimos una escapada para cenar en un tailandés cercano.
La mayoría de españoles llegaron ese día y tras la cena les entró la modorra y el cansancio, por lo que se fueron a sus respectivos (y lejanos) hoteles.

Yo decidí quedarme y lo pasé como un niño, pues el bar consistía en una especie de cyber café, con muchísimas consolas, especialmente para jugar a dobles. Moló jugar contra Alan, Rudy, Martin, Lucía y Michal al Mario Kart y a la versión de PS4 de Street Fighter (¡cómo evolucionó este juego, pues yo sólo jugué la versión 2 en las recreativas de mi ciudad!).
Martin vs Alan. Round 1, fight! :PAl Mario Kart: Lucia 1 - Costales 0Con miedo a perder el último metro y ya un poco cansado del largo día, acompañé a Olive cuando marchó del bar.

Día 2 de la Ubucon, 9 de Septiembre, Sábado
La jornada la abrió Slimbook presentando sus portátiles con Linux preinstalado y la finalizó Martin Wimpress presentando el inminente Ubuntu MATE 17.10, y por cierto, sé de buena tinta que convenció a muchísimos de los asistentes que era reticentes a MATE.
Charla de Slimbook
Descubriendo Ubuntu MATE 17.10

A nivel personal, Paco Molinero y yo grabamos un nuevo podcast de Ubuntu y otras hierbas. Un capítulo muy especial, pues teniendo a mano a personas tan influyentes e importantes de la comunidad, no podíamos menos que entrevistar a Alan Pope, Martin Wimpress, Rudy y Miguel. En unos días publicamos el podcast por los canales habituales ;) 
Costales | Paco Molinero | Alan Pope
También me sorprendió la gran asistencia a mi charla de "Privacidad en la Red". Incluso el propio Ubuntu twitteó sobre ella |o/
Mi charla
Tras las conferencias, el evento social fue en el mismo bar de las bóvedas, junto al río. Allí, Rudy y Olive me hicieron una encerrona y me trajeron una gaita, escocesa, para más inri. Así que tras años sin tocar mi gaita asturiana, afortunado fui de poder hacer sonar algunas notas :P
let's play!Continuó con un concierto que dio paso a la cena y sobremesa, que disfruté y mucho, con Paul (de UBPorts), Santiago (un nuevo amigo, que se acercó gracias a dar anuncia del evento en nuestro podcast :O), los chicos de Slimbook y Miguel.Los franceses, como grandes anfitriones que son, se acercaban sin miedo a la mesa llena de españoles para socializar y dar sentido a esa palabra que es 'comunidad' :)) ¡Olé por ellos!

Día 3 de la Ubucon, 10 de Septiembre, domingo
Último día de la 2ª Ubucon Europea.Destaco el taller de cómo crear una aplicación snap impartido por Alan y Martin. Rudy y Vincent dieron conferencias sobre la comunidad ubuntera, especialmente la francesa, revisando eventos en los que atraen a miles de personas, como pueden ser el webCafe y la Ubuntu Party. Philip Clay también colaboró en su segunda Ubucon Europea explicando cómo personalizar GNOME en la próxima versión de Ubuntu.
Curso de snapRudy en su charla
Me encantó una sesión de podcasters moderada por Alan, con Rudy, Martin, Tiago, Max y Marius Quabeck, la cual tengo muchas ganas de volver a escuchar en cuanto esté disponible online.
Podcast conjunto
Antes de finalizar las conferencias, Dustin Kirkland realizó una keynote sobre qué esperar en la futura versión LTS 18.04, tanto en el escritorio, en el servidor, como en el IoT. Muy interesante y parece que Ubuntu se ha tomado muy en serio escuchar más a la comunidad y se vieron todas las áreas en las que Ubuntu es relevante.
Qué veremos en la futura LTS
Mucho feedback de la comunidad
Olive y Rudy despidieron el evento agradeciendo a todos los participantes su asistencia.Pero que el evento finalice, no implica que todos nos vayamos para el hotel ;) Cerramos la noche cenando en una pizzería cercana y la sobremesa fue única, con Alan provocando a diestro y siniestro. Eso sí, también le provocaron, por ejemplo Philip le preguntaba: "Is the snapd package available as a flatpak?" xD
cena
Un cubo, ingeniería alemana :P
The end
Al día siguiente, nos acercamos Miguel y yo a visitar la Torre Eiffel. Tras ello, Miguel se fue al aeropuerto y yo deambulé por las calles parisinas, calles de posiblemente la ciudad más bohemia del mundo. Una capital que albergó el evento ubuntero más importante de Europa y parte del mundo. Por el pasaron miles de asistentes, se hicieron libres muchísimos ordenadores, se compartió el conocimiento con decenas de charlas... pero si me tengo que quedar con algo, me quedo, sin dudarlo, con los eventos sociales, con toda la gente nueva que conocí o que volví a ver y los buenos momentos que compartí con ellos.
Paris

Para finalizar, quiero felicitar a todo el equipo francés. Han hecho un trabajo perfecto, impresionante y con toda la pasión del mundo. ¡Gracias y hasta la próxima compañeros!

LOL :))) ¡Grandeeee Rudy!

Dustin Kirkland: Running Ubuntu Containers with Hyper-V Isolation on Windows 10 and Windows Server

Planet Ubuntu - Mër, 13/09/2017 - 6:00md

Canonical and Microsoft have teamed up to deliver an truly special experience -- running Ubuntu containers with Hyper-V Isolation on Windows 10 and Windows Servers!

We have published a fantastic tutorial at https://ubu.one/UhyperV, with screenshots and easy-to-follow instructions.  You should be up and running in minutes!

Follow that tutorial, and you'll be able to launch Ubuntu containers with Hyper-V isolation by running the following directly from a Windows Powershell:
  • docker run -it ubuntu bash
Cheers!
Dustin

Route-based IPsec VPN on Linux with strongSwan

Planet Debian - Mër, 13/09/2017 - 10:20pd

A common way to establish an IPsec tunnel on Linux is to use an IKE daemon, like the one from the strongSwan project, with a minimal configuration1:

conn V2-1 left = 2001:db8:1::1 leftsubnet = 2001:db8:a1::/64 right = 2001:db8:2::1 rightsubnet = 2001:db8:a2::/64 authby = psk auto = route

The same configuration can be used on both sides. Each side will figure out if it is “left” or “right”. The IPsec site-to-site tunnel endpoints are 2001:db8:­1::1 and 2001:db8:­2::1. The protected subnets are 2001:db8:­a1::/64 and 2001:db8:­a2::/64. As a result, strongSwan configures the following policies in the kernel:

$ ip xfrm policy src 2001:db8:a1::/64 dst 2001:db8:a2::/64 dir out priority 399999 ptype main tmpl src 2001:db8:1::1 dst 2001:db8:2::1 proto esp reqid 4 mode tunnel src 2001:db8:a2::/64 dst 2001:db8:a1::/64 dir fwd priority 399999 ptype main tmpl src 2001:db8:2::1 dst 2001:db8:1::1 proto esp reqid 4 mode tunnel src 2001:db8:a2::/64 dst 2001:db8:a1::/64 dir in priority 399999 ptype main tmpl src 2001:db8:2::1 dst 2001:db8:1::1 proto esp reqid 4 mode tunnel […]

This kind of IPsec tunnel is a policy-based VPN: encapsulation and decapsulation are governed by these policies. Each of them contains the following elements:

  • a direction (out, in or fwd2),
  • a selector (source subnet, destination subnet, protocol, ports),
  • a mode (transport or tunnel),
  • an encapsulation protocol (esp or ah), and
  • the endpoint source and destination addresses.

When a matching policy is found, the kernel will look for a corresponding security association (using reqid and the endpoint source and destination addresses):

$ ip xfrm state src 2001:db8:1::1 dst 2001:db8:2::1 proto esp spi 0xc1890b6e reqid 4 mode tunnel replay-window 0 flag af-unspec auth-trunc hmac(sha256) 0x5b68[…]8ba2904 128 enc cbc(aes) 0x8e0e377ad8fd91e8553648340ff0fa06 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 […]

If no security association is found, the packet is put on hold and the IKE daemon is asked to negotiate an appropriate one. Otherwise, the packet is encapsulated. The receiving end identifies the appropriate security association using the SPI in the header. Two security associations are needed to establish a bidirectionnal tunnel:

$ tcpdump -pni eth0 -c2 -s0 esp 13:07:30.871150 IP6 2001:db8:1::1 > 2001:db8:2::1: ESP(spi=0xc1890b6e,seq=0x222) 13:07:30.872297 IP6 2001:db8:2::1 > 2001:db8:1::1: ESP(spi=0xcf2426b6,seq=0x204)

All IPsec implementations are compatible with policy-based VPNs. However, some configurations are difficult to implement. For example, consider the following proposition for redundant site-to-site VPNs:

A possible configuration between V1-1 and V2-1 could be:

conn V1-1-to-V2-1 left = 2001:db8:1::1 leftsubnet = 2001:db8:a1::/64,2001:db8:a6::cc:1/128,2001:db8:a6::cc:5/128 right = 2001:db8:2::1 rightsubnet = 2001:db8:a2::/64,2001:db8:a6::/64,2001:db8:a8::/64 authby = psk keyexchange = ikev2 auto = route

Each time a subnet is modified on one site, the configurations need to be updated on all sites. Moreover, overlapping subnets (2001:db8:­a6::/64 on one side and 2001:db8:­a6::cc:1/128 at the other) can also be problematic.

The alternative is to use route-based VPNs: any packet traversing a pseudo-interface will be encapsulated using a security policy bound to the interface. This brings two features:

  1. Routing daemons can be used to distribute routes to be protected by the VPN. This decreases the administrative burden when many subnets are present on each side.
  2. Encapsulation and decapsulation can be executed in a different routing instance or namespace. This enables a clean separation between a private routing instance (where VPN users are) and a public routing instance (where VPN endpoints are).
Route-based VPN on Juniper

Before looking at how to achieve that on Linux, let’s have a look at the way it works with a JunOS-based platform (like a Juniper vSRX). This platform as long-standing history of supporting route-based VPNs (a feature already present in the Netscreen ISG platform).

Let’s assume we want to configure the IPsec VPN from V3-2 to V1-1. First, we need to configure the tunnel interface and bind it to the “private” routing instance containing only internal routes (with IPv4, they would have been RFC 1918 routes):

interfaces { st0 { unit 1 { family inet6 { address 2001:db8:ff::7/127; } } } } routing-instances { private { instance-type virtual-router; interface st0.1; } }

The second step is to configure the VPN:

security { /* Phase 1 configuration */ ike { proposal IKE-P1 { authentication-method pre-shared-keys; dh-group group20; encryption-algorithm aes-256-gcm; } policy IKE-V1-1 { mode main; proposals IKE-P1; pre-shared-key ascii-text "d8bdRxaY22oH1j89Z2nATeYyrXfP9ga6xC5mi0RG1uc"; } gateway GW-V1-1 { ike-policy IKE-V1-1; address 2001:db8:1::1; external-interface lo0.1; general-ikeid; version v2-only; } } /* Phase 2 configuration */ ipsec { proposal ESP-P2 { protocol esp; encryption-algorithm aes-256-gcm; } policy IPSEC-V1-1 { perfect-forward-secrecy keys group20; proposals ESP-P2; } vpn VPN-V1-1 { bind-interface st0.1; df-bit copy; ike { gateway GW-V1-1; ipsec-policy IPSEC-V1-1; } establish-tunnels on-traffic; } } }

We get a route-based VPN because we bind the st0.1 interface to the VPN-V1-1 VPN. Once the VPN is up, any packet entering st0.1 will be encapsulated and sent to the 2001:db8:­1::1 endpoint.

The last step is to configure BGP in the “private” routing instance to exchange routes with the remote site:

routing-instances { private { routing-options { router-id 1.0.3.2; maximum-paths 16; } protocols { bgp { preference 140; log-updown; group v4-VPN { type external; local-as 65003; hold-time 6; neighbor 2001:db8:ff::6 peer-as 65001; multipath; export [ NEXT-HOP-SELF OUR-ROUTES NOTHING ]; } } } } }

The export filter OUR-ROUTES needs to select the routes to be advertised to the other peers. For example:

policy-options { policy-statement OUR-ROUTES { term 10 { from { protocol ospf3; route-type internal; } then { metric 0; accept; } } } }

The configuration needs to be repeated for the other peers. The complete version is available on GitHub. Once the BGP sessions are up, we start learning routes from the other sites. For example, here is the route for 2001:db8:­a1::/64:

> show route 2001:db8:a1::/64 protocol bgp table private.inet6.0 best-path private.inet6.0: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2001:db8:a1::/64 *[BGP/140] 01:12:32, localpref 100, from 2001:db8:ff::6 AS path: 65001 I, validation-state: unverified to 2001:db8:ff::6 via st0.1 > to 2001:db8:ff::14 via st0.2

It was learnt both from V1-1 (through st0.1) and V1-2 (through st0.2). The route is part of the private routing instance but encapsulated packets are sent/received in the public routing instance. No route-leaking is needed for this configuration. The VPN cannot be used as a gateway from internal hosts to external hosts (or vice-versa). This could also have been done with JunOS’ security policies (stateful firewall rules) but doing the separation with routing instances also ensure routes from different domains are not mixed and a simple policy misconfiguration won’t lead to a disaster.

Route-based VPN on Linux

Starting from Linux 3.15, a similar configuration is possible with the help of a virtual tunnel interface3. First, we create the “private” namespace:

# ip netns add private # ip netns exec private sysctl -qw net.ipv6.conf.all.forwarding=1

Any “private” interface needs to be moved to this namespace (no IP is configured as we can use IPv6 link-local addresses):

# ip link set netns private dev eth1 # ip link set netns private dev eth2 # ip netns exec private ip link set up dev eth1 # ip netns exec private ip link set up dev eth2

Then, we create vti6, a tunnel interface (similar to st0.1 in the JunOS example):

# ip tunnel add vti6 \ mode vti6 \ local 2001:db8:1::1 \ remote 2001:db8:3::2 \ key 6 # ip link set netns private dev vti6 # ip netns exec private ip addr add 2001:db8:ff::6/127 dev vti6 # ip netns exec private sysctl -qw net.ipv4.conf.vti6.disable_policy=1 # ip netns exec private sysctl -qw net.ipv4.conf.vti6.disable_xfrm=1 # ip netns exec private ip link set vti6 mtu 1500 # ip netns exec private ip link set vti6 up

The tunnel interface is created in the initial namespace and moved to the “private” one. It will remember its original namespace where it will process encapsulated packets. Any packet entering the interface will temporarily get a firewall mark of 6 that will be used only to match the appropriate IPsec policy4 below. For some reason, the kernel sets a too low MTU on the interface. We set it to 1500 and let PMTUD do its work (the MTU is dependant on the ciphers used for the IPsec tunnel).

We can then configure strongSwan5:

conn V3-2 left = 2001:db8:1::1 leftsubnet = ::/0 right = 2001:db8:3::2 rightsubnet = ::/0 authby = psk mark = 6 auto = route keyexchange = ikev2 keyingtries = %forever ike = aes256gcm16-prfsha384-ecp384! esp = aes256gcm16-prfsha384-ecp384! mobike = no

The IKE daemon configures the following policies in the kernel:

$ ip xfrm policy src ::/0 dst ::/0 dir out priority 399999 ptype main mark 0x6/0xffffffff tmpl src 2001:db8:1::1 dst 2001:db8:3::2 proto esp reqid 1 mode tunnel src ::/0 dst ::/0 dir fwd priority 399999 ptype main mark 0x6/0xffffffff tmpl src 2001:db8:3::2 dst 2001:db8:1::1 proto esp reqid 1 mode tunnel src ::/0 dst ::/0 dir in priority 399999 ptype main mark 0x6/0xffffffff tmpl src 2001:db8:3::2 dst 2001:db8:1::1 proto esp reqid 1 mode tunnel […]

Those policies are used for any source or destination as long as the firewall mark is equal to 6, which matches the mark configured for the tunnel interface.

The last step is to configure BGP to exchange routes. We can use BIRD for this:

router id 1.0.1.1; protocol device { scan time 10; } protocol kernel { persist; learn; import all; export all; merge paths yes; } protocol bgp IBGP_V3_2 { local 2001:db8:ff::6 as 65001; neighbor 2001:db8:ff::7 as 65003; import all; export where ifname ~ "eth*"; preference 160; hold time 6; }

Once BIRD is started in the “private” namespace, we can check routes are learned correctly:

$ ip netns exec private ip -6 route show 2001:db8:a3::/64 2001:db8:a3::/64 proto bird metric 1024 nexthop via 2001:db8:ff::5 dev vti5 weight 1 nexthop via 2001:db8:ff::7 dev vti6 weight 1

The above route was learnt from both V3-1 (through vti5) and V3-2 (through vti6). Like for the JunOS version, there is no route-leaking between the “private” namespace and the initial one. The VPN cannot be used as a gateway between the two namespaces, only for encapsulation. This also prevent a misconfiguration (for example, IKE daemon not running) from allowing packets to leave the private network.

As a bonus, unencrypted traffic can be observed with tcpdump on the tunnel interface:

$ ip netns exec private tcpdump -pni vti6 icmp6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vti6, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 20:51:15.258708 IP6 2001:db8:a1::1 > 2001:db8:a3::1: ICMP6, echo request, seq 69 20:51:15.260874 IP6 2001:db8:a3::1 > 2001:db8:a1::1: ICMP6, echo reply, seq 69

You can find all the configuration files for this example on GitHub. The documentation of strongSwan also features a page about route-based VPNs.

  1. Everything in this post should work with Libreswan. ↩

  2. fwd is for incoming packets on non-local addresses. It only makes sense in transport mode and is a Linux-only particularity. ↩

  3. Virtual tunnel interfaces (VTI) were introduced in Linux 3.6 (for IPv4) and Linux 3.12 (for IPv6). Appropriate namespace support was added in 3.15. KLIPS, an alternative out-of-tree stack available since Linux 2.2, also features tunnel interfaces. ↩

  4. The mark is set right before doing a policy lookup and restored after that. Consequently, it doesn’t affect other possible uses (filtering, routing). However, as Netfilter can also set a mark, one should be careful for conflicts. ↩

  5. The ciphers used here are the strongest ones currently possible while keeping compatibility with JunOS. The documentation for strongSwan contains a complete list of supported algorithms as well as security recommendations to choose them. ↩

Vincent Bernat https://vincent.bernat.im/en Vincent Bernat

Reproducible Builds: Weekly report #124

Planet Debian - Mër, 13/09/2017 - 9:48pd

Here's what happened in the Reproducible Builds effort between Sunday September 3 and Saturday September 9 2017:

Media coverage GSoC and Outreachy updates

Debian will participate in this year's Outreachy initiative and the Reproducible Builds is soliciting mentors and students to join this round.

For more background please see the following mailing list posts: 1, 2 & 3.

Reproduciblity work in Debian

In addition, the following NMUs were accepted:

Reproduciblity work in other projects

Patches sent upstream:

Packages reviewed and fixed, and bugs filed Reviews of unreproducible packages

3 package reviews have been added, 2 have been updated and 2 have been removed in this week, adding to our knowledge about identified issues.

Weekly QA work

During our reproducibility testing, FTBFS bugs have been detected and reported by:

  • Adrian Bunk (15)
diffoscope development

Development continued in git, including the following contributions:

Mattia Rizzolo also uploaded the version 86 released last week to stretch-backports.

reprotest development tests.reproducible-builds.org Misc.

This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Mattia Rizzolo & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Reproducible builds folks https://reproducible.alioth.debian.org/blog/ Reproducible builds blog

My Free Software Activities in August 2017

Planet Debian - Mër, 13/09/2017 - 1:04pd

Welcome to gambaru.de. Here is my monthly report that covers what I have been doing for Debian. If you’re interested in  Java, Games and LTS topics, this might be interesting for you.

DebConf 17 in Montreal

I traveled to DebConf 17 in Montreal/Canada. I arrived on 04. August and met a lot of different people which I only knew by name so far. I think this is definitely one of the best aspects of real life meetings, putting names to faces and getting to know someone better. I totally enjoyed my stay and I would like to thank all the people who were involved in organizing this event. You rock! I also gave a talk about the “The past, present and future of Debian Games”,  listened to numerous other talks and got a nice sunburn which luckily turned into a more brownish color when I returned home on 12. August. The only negative experience I made was with my airline which was supposed to fly me home to Frankfurt again. They decided to cancel the flight one hour before check-in for unknown reasons and just gave me a telephone number to sort things out.  No support whatsoever. Fortunately (probably not for him) another DebConf attendee suffered the same fate and together we could find another flight with Royal Air Maroc the same day. And so we made a short trip to Casablanca/Morocco and eventually arrived at our final destination in Frankfurt a few hours later. So which airline should you avoid at all costs (they still haven’t responded to my refund claims) ? It’s WoW-Air from Iceland. (just wow)

Debian Games Debian Java Debian LTS

This was my eighteenth month as a paid contributor and I have been paid to work 20,25 hours on Debian LTS, a project started by Raphaël Hertzog. In that time I did the following:

  • From 31. July until 06. August I was in charge of our LTS frontdesk. I triaged bugs in tinyproxy, mantis, sox, timidity, ioquake3, varnish, libao, clamav, binutils, smplayer, libid3tag, mpg123 and shadow.
  • DLA-1064-1. Issued a security update for freeradius fixing 6 CVE.
  • DLA-1068-1. Issued a security update for git fixing 1 CVE.
  • DLA-1077-1. Issued a security update for faad2 fixing 11 CVE.
  • DLA-1083-1. Issued a security update for openexr fixing 3 CVE.
  • DLA-1095-1. Issued a security update for freerdp fixing 5 CVE.
Non-maintainer upload
  • I uploaded a security fix for openexr (#864078) to fix CVE-2017-9110, CVE-2017-9112 and CVE-2017-9116.

Thanks for reading and see you next time.

Apo https://gambaru.de/blog planetdebian – gambaru.de

James Page: OpenStack Charms 17.08 release!

Planet Ubuntu - Mar, 12/09/2017 - 11:59md

The OpenStack Charms team is pleased to announce that the 17.08 release of the OpenStack Charms is now available from jujucharms.com!

In addition to 204 bug fixes across the charms and support for OpenStack Pike, this release includes a new charm for Gnocchi, support for Neutron internal DNS, Percona Cluster performance tuning and much more.

For full details of all the new goodness in this release please refer to the release notes.

Thanks go to the following people who contributed to this release:

Nobuto Murata
Mario Splivalo
Ante Karamatić
zhangbailin
Shane Peters
Billy Olsen
Tytus Kurek
Frode Nordahl
Felipe Reyes
David Ames
Jorge Niedbalski
Daniel Axtens
Edward Hope-Morley
Chris MacNaughton
Xav Paice
James Page
Jason Hobbs
Alex Kavanagh
Corey Bryant
Ryan Beisner
Graham Burgess
Andrew McLeod
Aymen  Frikha
Hua Zhang
Alvaro Uría
Peter Sabaini

EOM

 

 


Google Hangouts in Debian testing (Buster)

Planet Debian - Mar, 12/09/2017 - 9:37md

Google offers a lot of software components packaged specifically for Debian and Debian-like Linux distributions. Examples are: Chrome, Earth and the Hangouts plugin. Also, there are many other Internet services doing the same: Spotify, Dropbox, etc. I’m really grateful for them, since this make our life easier.

Problem is that our ecosystem is rather complex, with many distributions and many versions out there. I guess is not an easy task for them to keep such a big variety of support variations.

In this particular case, it seems Google doesn’t support Debian testing in their .deb packages. In this case, testing means Debian Buster. And the same happens with the official Spotify client package.

I’ve identified several issues with them, to name a few:

  • packages depends on lsb-core, no longer present in Buster testing.
  • packages depends on libpango1.0-0, however testing contains libpango-1.0-0

I’m in need of using Google Hangout so I’ve been forced to solve this situation by editing the .deb package provided by Google.

Simple steps:

  • 1) create a temporal working directory
% user@debian:~ $ mkdir pkg % user@debian:~ $ cd pkg/
  • 2) get the original .deb package, the Google Hangout talk plugin.
% user@debian:~/pkg $ wget https://dl.google.com/linux/direct/google-talkplugin_current_amd64.deb [...]
  • 3) extract the original .deb package
% user@debian:~/pkg $ dpkg-deb -R google-talkplugin_current_amd64.deb google-talkplugin_current_amd64/
  • 4) edit the control file, replace libpango1.0-0 with libpango-1.0-0
% user@debian:~/pkg $ nano google-talkplugin_current_amd64/DEBIAN/control
  • 5) rebuild the package and install it!
% user@debian:~/pkg $ dpkg -b google-talkplugin_current_amd64 % user@debian:~/pkg $ sudo dpkg -i google-talkpluging_current_amd64.deb

I have yet to investigate how to workaround the lsb-core thing, so still I can’t use Google Earth.

Arturo Borrero González http://ral-arturo.org/ ral-arturo.org

Jonathan Riddell: KGraphViewer 2.4.0

Planet Ubuntu - Mar, 12/09/2017 - 5:13md

KGraphViewer 2.4.0 has been released.

KGraphViewer is a visualiser for Graphviz’s DOT format of graphs.
https://www.kde.org/applications/graphics/kgraphviewer

This ports KGraphViewer to use KDE Frameworks 5 and Qt 5.

It can be used by massif-visualizer to add graphing features.

Download from:
https://download.kde.org/stable/kgraphviewer/2.4.0/

sha256:
88c2fd6514e49404cfd76cdac8ae910511979768477f77095d2f53dca0f231b4 kgraphviewer-2.4.0.tar.xz

Signed with my PGP key
2D1D 5B05 8835 7787 DE9E E225 EC94 D18F 7F05 997E
Jonathan Riddell <jr@jriddell.org>
kgraphviewer-2.4.0.tar.xz.sig

by

rANS encoding of signed coefficients

Planet Debian - Mar, 12/09/2017 - 1:00pd

I'm currently trying to make sense of some still image coding (more details to come at a much later stage!), and for a variety of reasons, I've chosen to use rANS as the entropy coder. However, there's an interesting little detail that I haven't actually seen covered anywhere; maybe it's just because I've missed something, or maybe because it's too blindingly obvious, but I thought I would document what I ended up with anyway. (I had hoped for something even more elegant, but I guess the obvious would have to do.)

For those that don't know rANS coding, let me try to handwave it as much as possible. Your state is typically a single word (in my case, a 32-bit word), which is refilled from the input stream as needed. The encoder and decoder works in reverse order; let's just talk about the decoder. Basically it works by looking at the lowest 12 (or whatever) bits of the decoder state, mapping each of those 2^12 slots to a decoded symbol. More common symbols are given more slots, proportionally to the frequency. Let me just write a tiny, tiny example with 2 bits and three symbols instead, giving four slots:

Lowest bits Symbol 00 0 01 0 10 1 11 2

Note that the zero coefficient here maps to one out of two slots (ie., a range); you don't choose which one yourself, the encoder stashes some information in there (which is used to recover the next control word once you know which symbol there is).

Now for the actual problem: When storing DCT coefficients, we typically want to also store a sign (ie., not just 1 or 2, but also -1/+1 and -2/+2). The statistical distribution is symmetrical, so the sign bit is incompressible (except that of course there's no sign bit needed for 0). We could have done this by introducing new symbols -1 and -2 in addition to our three other ones, but this means we'll need more bits of precision, and accordingly larger look-up tables (which is negative for performance). So let's find something better.

We could also simply store it separately somehow; if the coefficient is non-zero, store the bits in some separate repository. Perhaps more elegantly, you can encode a second symbol in the rANS stream with probability 1/2, but this is more expensive computationally. But both of these have the problem that they're divergent in terms of control flow; nonzero coefficients potentially need to do a lot of extra computation and even loads. This isn't nice for SIMD, and it's not nice for GPU. It's generally not really nice.

The solution I ended up with was simulating a larger table with a smaller one. Simply rotate the table so that the zero symbol has the top slots instead of the bottom slots, and then replicate the rest of the table. For instance, take this new table:

Lowest bits Symbol 000 1 001 2 010 0 011 0 100 0 101 0 110 -1 111 -2

(The observant reader will note that this doesn't describe the exact same distribution as last time—zero has twice the relative frequency as in the other table—but ignore that for the time being.)

In this case, the bottom half of the table doesn't actually need to be stored! We know that if the three bottom bits are >= 110 (6 in decimal), we have a negative value, can subtract 6, and then continue decoding. If we are go past the end of our 2-bit table despite that, we know we are decoding a zero coefficient (which doesn't have a sign), so we can just clamp the read; or for a GPU, reads out-of-bounds on a texture will typically return 0 anyway. So it all works nicely, and the divergent I/O is gone.

If this pickled your interest, you probably want to read up on rANS in general; Fabian Giesen (aka ryg) has some notes that work as a good starting point, but beware; some of this is pretty confusing. :-)

Steinar H. Gunderson http://blog.sesse.net/ Steinar H. Gunderson

Scott Moser: Podcast.__init__ episode on cloud-init

Planet Ubuntu - Hën, 11/09/2017 - 3:42md
Cloud-init is the subject for the most recent episode of Podcast.__init__.
Go and have a listen to Episode 126.

I really enjoyed talking to Tobias about cloud-init and some of the difficulties of the project and goals for the future.

Enjoy!

Debian-Administration.org is closing down

Planet Debian - Dje, 10/09/2017 - 11:00md

After 13 years the Debian-Administration website will be closing down towards the end of the year.

The site will go read-only at the end of the month, and will slowly be stripped back from that point towards the end of the year - leaving only a static copy of the articles, and content.

This is largely happening due to lack of content. There were only two articles posted last year, and every time I consider writing more content I lose my enthusiasm.

There was a time when people contributed articles, but these days they tend to post such things on their own blogs, on medium, on Reddit, etc. So it seems like a good time to retire things.

An official notice has been posted on the site-proper.

Steve Kemp https://blog.steve.fi/ Steve Kemp's Blog

Stuart Langridge: The Niamh prime

Planet Ubuntu - Dje, 10/09/2017 - 9:32md

A bit of maths-y fiddling around on a Sunday afternoon.

Fascinating video on the Trinity Hall prime at Numberphile:

Apparently, Professor James McKee found a prime number which, when written out as ASCII art, looks like the crest of Trinity Hall college. Jack Hodkinson at Cambridge then searched for and found a prime which looks like a picture of Corpus Christi college (via Futility Closet). That seems like a cool idea. So, with a bit of help from aalib in JavaScript and the Miller-Rabin primality test, plus a bit of scaling images up and down in Gimp, I found this 2,850-digit prime:

777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,577,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­777,777,777,­752,385,356,­867,777,777,­777,777,777,­777,777,777,­777,777,777,­775,352,235,­666,688,668,­667,777,777,­777,777,777,­777,777,777,­777,776,765,­555,556,666,­856,868,667,­777,777,777,­777,777,777,­777,777,777,­222,335,666,­666,866,686,­666,665,777,­777,777,777,­777,777,777,­777,355,336,­358,866,556,­666,655,665,­655,777,777,­777,777,777,­777,777,733,­552,236,666,­666,655,665,­665,666,555,­777,777,777,­777,777,777,­777,276,265,­666,666,656,­655,555,555,­555,533,777,­777,777,777,­777,777,253,­252,566,666,­665,555,556,­555,555,565,­557,777,777,­777,777,777,­725,222,236,­666,565,555,­555,556,555,­535,355,237,­777,777,777,­777,772,266,­725,366,535,­555,355,555,­555,553,553,­533,577,777,­777,777,777,­272,637,356,­655,555,555,­353,535,556,­655,355,332,­277,777,777,­777,772,235,­775,355,665,­553,355,353,­535,533,555,­555,223,777,­777,777,777,­322,222,255,­555,556,353,­555,355,336,­355,653,533,­537,777,777,­777,772,222,­225,555,565,­555,355,335,­355,356,555,­655,353,237,­777,777,777,­772,272,355,­553,553,355,­535,353,365,­355,355,553,­523,577,777,­777,777,332,­333,566,333,­553,555,533,­355,355,555,­555,353,555,­677,777,777,­777,332,355,­555,555,555,­555,555,553,­555,535,555,­666,556,777,­777,777,775,­533,355,535,­355,553,565,­535,353,655,­655,555,565,­557,777,777,­777,756,533,­555,533,335,­353,566,655,­353,566,535,­656,655,577,­777,777,777,­565,353,535,­535,553,335,­566,666,555,­666,568,566,­665,777,777,­777,775,633,­535,555,555,­555,535,565,­556,555,666,­566,666,677,­777,777,777,­758,333,333,­355,555,656,­556,565,866,­666,866,658,­667,777,777,­777,777,582,­233,333,333,­355,565,555,­566,666,666,­868,666,677,­777,777,777,­775,822,333,­333,333,535,­555,556,666,­666,668,688,­586,777,777,­777,777,736,­355,333,333,­355,556,555,­636,666,686,­688,888,557,­777,777,777,­777,565,555,­555,333,555,­566,666,565,­686,666,886,­886,777,777,­777,777,776,­656,888,853,­335,556,686,­556,666,666,­868,886,887,­777,777,777,­777,775,356,­368,532,355,­555,688,666,­866,666,668,­668,877,777,­777,777,777,­732,233,553,­223,323,335,­533,556,666,­686,686,686,­777,777,777,­777,777,323,­333,332,222,­233,332,233,­568,665,666,­656,337,777,­777,777,777,­773,233,333,­322,222,223,­222,223,566,­556,655,533,­777,777,777,­777,777,722,­333,232,222,­222,233,222,­225,665,555,­632,277,777,­777,777,777,­777,323,333,­322,222,223,­222,222,236,­553,553,222,­777,777,777,­777,777,777,­233,232,222,­223,232,222,­223,355,533,­552,277,777,­777,777,777,­777,772,333,­333,222,233,­322,222,223,­353,233,355,­777,777,777,­777,777,777,­723,333,355,­665,533,233,­333,333,322,­335,677,777,­777,777,777,­777,777,735,­533,333,222,­233,333,333,­332,223,356,­777,777,777,­777,777,777,­777,555,333,­232,222,333,­333,333,222,­233,677,777,­777,777,777,­777,777,772,­533,332,222,­222,333,333,­322,222,255,­777,777,777,­777,777,777,­777,775,356,­566,665,553,­333,333,222,­223,557,777,­777,777,777,­777,777,777,­733,335,333,­332,223,333,­332,222,233,­577,777,777,­777,777,777,­777,777,233,­335,332,222,­223,332,322,­222,233,777,­777,777,777,­777,777,777,­777,333,232,­222,222,223,­332,222,222,­237,777,777,­777,777,777,­777,777,773,­222,222,222,­222,223,222,­322,222,377,­777,777,777,­777,777,777,­777,777,222,­222,222,222,­323,332,222,­223,777,777,­777,777,777,­777,777,777,­773,232,222,­222,333,353,­222,222,227,­777,777,777,­777,777,777,­777,777,733,­332,222,223,­355,322,222,­222,277,777,­777,777,777,­777,777,777,­777,755,333,­333,555,533,­222,222,222,­277,777,777,­777,777,777,­777,777,777,­777,775,555,­555,322,222,­222,222,777,­777,777,777,­777,777,777,­777,777,777,­755,555,533,­222,222,222,­227,777,777,­777,777,777,­777,777,777,­777,777,755,­553,332,222,­222,222,227,­777,777,777,­777,777,777,­777,777,777,­777,555,533,­322,222,222,­222,227,777,­777,777,777,­777,777,777,­777,777,773,­553,332,222,­222,222,222,­277,777,777,­777,777,777,­777,777,777,­777,735,533,­322,222,222,­222,222,277,­779,769

although it looks rather better when properly formatted.

77777777777777777777777777777777777777777777777777 77777777777777777777777777777777777777777777777777 77777777777777777777777577777777777777777777777777 77777777777777777777775238535686777777777777777777 77777777777777777753522356666886686677777777777777 77777777777777776765555556666856868667777777777777 77777777777777722233566666686668666666577777777777 77777777777773553363588665566666556656557777777777 77777777777733552236666666655665665666555777777777 77777777777727626566666665665555555555553377777777 77777777772532525666666655555565555555655577777777 77777777725222236666565555555556555535355237777777 77777777226672536653555535555555555355353357777777 77777772726373566555555553535355566553553322777777 77777772235775355665553355353535533555555223777777 77777732222225555555635355535533635565353353777777 77777722222255555655553553353553565556553532377777 77777772272355553553355535353365355355553523577777 77777733233356633355355553335535555555535355567777 77777773323555555555555555555535555355556665567777 77777775533355535355553565535353655655555565557777 77777775653355553333535356665535356653565665557777 77777775653535355355533355666665556665685666657777 77777775633535555555555535565556555666566666677777 77777775833333335555565655656586666686665866777777 77777775822333333333555655555666666668686666777777 77777775822333333333535555556666666668688586777777 77777773635533333335555655563666668668888855777777 77777775655555553335555666665656866668868867777777 77777776656888853335556686556666666868886887777777 77777777535636853235555568866686666666866887777777 77777777322335532233233355335566666866866867777777 77777777323333332222233332233568665666656337777777 77777777323333332222222322222356655665553377777777 77777777223332322222222332222256655556322777777777 77777777323333322222223222222236553553222777777777 77777777723323222222323222222335553355227777777777 77777777723333332222333222222233532333557777777777 77777777723333355665533233333333322335677777777777 77777777773553333322223333333333222335677777777777 77777777775553332322223333333332222336777777777777 77777777772533332222222333333322222255777777777777 77777777777535656666555333333322222355777777777777 77777777777333353333322233333322222335777777777777 77777777777233335332222223332322222233777777777777 77777777777733323222222222333222222223777777777777 77777777777732222222222222232223222223777777777777 77777777777777222222222222323332222223777777777777 77777777777777323222222233335322222222777777777777 77777777777777333322222233553222222222777777777777 77777777777777755333333555533222222222277777777777 77777777777777777777555555532222222222277777777777 77777777777777777777555555332222222222277777777777 77777777777777777777755553332222222222227777777777 77777777777777777777755553332222222222222777777777 77777777777777777777735533322222222222222777777777 77777777777777777777735533322222222222222277779769

I think I’ll call it the Niamh Prime.

Secure traffic to ZNC on Synology with Let’s Encrypt

Planet Debian - Dje, 10/09/2017 - 6:40md

I’ve been using IRC since late 1990’s, and I continue to do so to this day due to it (still) being one of the driving development forces in various open source communities. Especially in Linux development … and some of my acquintances I can only get in touch with via IRC :)

My Setup

On my Synology NAS I run ZNC (IRC bouncer/proxy) to which I connect using various IRC clients (irssi/XChat Azure/AndChat) from various platforms (Linux/Mac/Android). In this case ZNC serves as a gateway and no matter which device/client I connect from, I’m always connected to same IRC servers/chat rooms/settings when I left off.

This is all fine and dandy, but connecting from external networks to ZNC means you will hand in your ZNC credentials in plain text. Which is a problem for me, even thought we’re “only” talking about IRC bouncer/proxy.

With that said, how do we encrypt external traffic to our ZNC?

HowTo: Chat securely with ZNC on Synology using Let’s Encrypt SSL certificate

For reference or more thorough explanation of some of the steps/topics please refer to: Secure (HTTPS) public access to Synology NAS using Let’s Encrypt (free) SSL certificate

Requirements:

  • Synology NAS running DSM >= 6.0
  • Sub/domain name with ability to update DNS records
  • SSH access to your Synology NAS

1: DNS setup

Create A record for sub/domain you’d like to use to connect to your ZNC and point it to your Synology NAS external (WAN) IP. For your reference, subdomain I’ll use is: irc.hodzic.org

2: Create Let’s Encrypt certificate

DSM: Control Panel > Security > Certificates > Add

Followed by:

Add a new certificate > Get a certificate from Let's Encrypt

Followed by adding domain name A record was created for in Step 1, i.e:

After certificate is created, don’t forget to configure newly created certificate to point to correct domain name, i.e:

3: Install ZNC

In case you already have ZNC installed, I suggest you remove it and do a clean install. Mainly due to some problems with package in past, where ZNC wouldn’t start automatically on boot which lead to creating projects like: synology-znc-autostart. In latest version, all of these problems have been fixed and couple of new features have been added.

ZNC can be installed using Synology’s Package Center, if community package sources are enabled. Which can simply be done by adding new package sources:

Name: SynoCommunity Location: http://packages.synocommunity.com

To successfuly authenticate newly added source, under “General” tab, “Trust Level” should be set to “Any publisher”

As part of installation process, ZNC config will be run with most sane/useful options and admin user will be created allowing you access to ZNC webadmin.

4: Secure access to ZNC webadmin

Now we want to bind our sub/domain created in “Step 1” to ZNC webadmin, and secure external access to it. This can be done by creating a reverse proxy.

As part of this, you need to know which port has been allocated for SSL in ZNC Webadmin, i.e:

In this case, we can see it’s 8251.

Reverse Proxy can be created in:

DSM: Control Panel > Application Portal > Reverse Proxy > Create

Where sub/domain created in “Step 1” needs to be point to ZNC SSL port on localhost, i.e:

ZNC Webadmin is now available via HTTPS on external network for the sub/domain you setup as part of Step 1, or in my case:

As part of this step, in ZNC webadmin I’d advise you to create IRC servers and chatrooms you would like to connect to later.

Step 5: Create .pem file from LetsEncrpyt certificate for ZNC to use

On Synology, Let’s Encrypt certificates are stored and located on:

/usr/syno/etc/certificate/_archive/

In case you have multiple certificates, based on date your certificate was created, you can determine in which directory is your newly generated certificated stored, i.e:

drwx------ 2 root root 4096 Sep 10 12:57 JeRh3Y

Once it’s determined which certifiate is the one we want use, generate .pem by running following:

sudo cat /usr/syno/etc/certificate/_archive/JeRh3Y/{privkey,cert,chain}.pem > /usr/local/znc/var/znc.pem

After this restart ZNC:

sudo /var/packages/znc/scripts/start-stop-status stop && sudo /var/packages/znc/scripts/start-stop-status start

6: Configure IRC client

In this example I’ll use XChat Azure on MacOS, and same procedure should be identical for HexChat/XChat clients on any other platform.

Altough all information is picked up from ZNC itself, user details will need to be filled in.

In my setup I automatically connect to freenode and oftc networks, so I created two for local network and two for external network usage, later is the one we’re concentrating on.

On “General” tab of our newly created server, hostname for our server should be the sub/domain we’ve setup as part of “Step 1”, and port number should be the one we defined in “Step 4”, SSL checkbox must be checked.

On “Connecting” tab “Server password” field needs to be filled in following format:

johndoe/freenode:password

Where, “johndoe” is ZNC username. “freenode” is ZNC network name, and “password” is ZNC password.

“freenode” in this case must first be created as part of ZNC webadmin configuration, mentioned in “step 4”. Same case is for oftc network configuration.

As part of establishing the connection, information about our Let’s Encrypt certificate will be displayed, after which connection will be established and you’ll be automatically logged into all chatrooms.

Happy hacking!

Adnan Hodzic http://foolcontrol.org FoolControl – Phear the penguin

Can you reproduce this Tails ISO image?

Planet Debian - Dje, 10/09/2017 - 4:27md

Thanks to a Mozilla Open Source Software award, we have been working on making the Tails ISO images build reproducibly.

We have made huge progress: since a few months, ISO images built by Tails core developers and our CI system have always been identical. But we're not done yet and we need your help!

Our first call for testing build reproducibility in August uncovered a number of remaining issues. We think that we have fixed them all since, and we now want to find out what other problems may prevent you from building our ISO image reproducibly.

Please try to build an ISO image today, and tell us whether it matches ours!

Build an ISO

These instructions have been tested on Debian Stretch and testing/sid. If you're using another distribution, you may need to adjust them.

If you get stuck at some point in the process, see our more detailed build documentation and don't hesitate to contact us:

Setup the build environment

You need a system that supports KVM, 1 GiB of free memory, and about 20 GiB of disk space.

  1. Install the build dependencies:

    sudo apt install \ git \ rake \ libvirt-daemon-system \ dnsmasq-base \ ebtables \ qemu-system-x86 \ qemu-utils \ vagrant \ vagrant-libvirt \ vmdebootstrap && \ sudo systemctl restart libvirtd

  2. Ensure your user is in the relevant groups:

    for group in kvm libvirt libvirt-qemu ; do sudo adduser "$(whoami)" "$group" done

  3. Logout and log back in to apply the new group memberships.

Build Tails 3.2~alpha2

This should produce a Tails ISO image:

git clone https://git-tails.immerda.ch/tails && \ cd tails && \ git checkout 3.2-alpha2 && \ git submodule update --init && \ rake build Send us feedback!

No matter how your build attempt turned out we are interested in your feedback.

Gather system information

To gather the information we need about your system, run the following commands in the terminal where you've run rake build:

sudo apt install apt-show-versions && \ ( for f in /etc/issue /proc/cpuinfo do echo "--- File: ${f} ---" cat "${f}" echo done for c in free locale env 'uname -a' '/usr/sbin/libvirtd --version' \ 'qemu-system-x86_64 --version' 'vagrant --version' do echo "--- Command: ${c} ---" eval "${c}" echo done echo '--- APT package versions ---' apt-show-versions qemu:amd64 linux-image-amd64:amd64 vagrant \ libvirt0:amd64 ) | bzip2 > system-info.txt.bz2

Then check that the generated file doesn't contain any sensitive information you do not want to leak:

bzless system-info.txt.bz2

Next, please follow the instructions below that match your situation!

If the build failed

Sorry about that. Please help us fix it by opening a ticket:

  • set Category to Build system;
  • paste the output of rake build;
  • attach system-info.txt.bz2 (this will publish that file).
If the build succeeded

Compute the SHA-512 checksum of the resulting ISO image:

sha512sum tails-amd64-3.2~alpha2.iso

Compare your checksum with ours:

9b4e9e7ee7b2ab6a3fb959d4e4a2db346ae322f9db5409be4d5460156fa1101c23d834a1886c0ce6bef2ed6fe378a7e76f03394c7f651cc4c9a44ba608dda0bc

If the checksums match: success, congrats for reproducing Tails 3.2~alpha2! Please send an email to tails-dev@boum.org (public) or tails@boum.org (private) with the subject "Reproduction of Tails 3.2~alpha2 successful" and system-info.txt.bz2 attached. Thanks in advance! Then you can stop reading here.

Else, if the checksums differ: too bad, but really it's good news as the whole point of the exercise is precisely to identify such problems :) Now you are in a great position to help improve the reproducibility of Tails ISO images by following these instructions:

  1. Install diffoscope version 83 or higher and all the packages it recommends. For example, if you're using Debian Stretch:

    sudo apt remove diffoscope && \ echo 'deb http://ftp.debian.org/debian stretch-backports main' \ | sudo tee /etc/apt/sources.list.d/stretch-backports.list && \ sudo apt update && \ sudo apt -o APT::Install-Recommends="true" \ install diffoscope/stretch-backports

  2. Download the official Tails 3.2~alpha2 ISO image.

  3. Compare the official Tails 3.2~alpha2 ISO image with yours:

    diffoscope \ --text diffoscope.txt \ --html diffoscope.html \ --max-report-size 262144000 \ --max-diff-block-lines 10000 \ --max-diff-input-lines 10000000 \ path/to/official/tails-amd64-3.2~alpha2.iso \ path/to/your/own/tails-amd64-3.2~alpha2.iso bzip2 diffoscope.{txt,html}

  4. Send an email to tails-dev@boum.org (public) or tails@boum.org (private) with the subject "Reproduction of Tails 3.2~alpha2 failed", attaching:

    • system-info.txt.bz2;
    • the smallest file among diffoscope.txt.bz2 and diffoscope.html.bz2, except if they are larger than 100 KiB, in which case better upload the file somewhere (e.g. share.riseup.net and share the link in your email.

Thanks a lot!

Credits

Thanks to Ulrike & anonym who authored a draft on which this blog post is based.

intrigeri https://people.debian.org/~intrigeri/blog/ intrigeri's blog

dot-zed archive file format

Planet Debian - Dje, 10/09/2017 - 3:50md

TL,DR: I reverse-engineered the .zed encrypted archive format.
Following a clean-room design, I'm providing a description that can be implemented by a third-party.
Interested?

(reference version at: https://www.beuc.net/zed/)

.zed archive file format Introduction

Archives with the .zed extension are conceptually similar to an encrypted .zip file.

In addition to a specific format, .zed files support multiple users: files are encrypted using the archive master key, which itself is encrypted for each user and/or authentication method (password, RSA key through certificate or PKCS#11 token). Metadata such as filenames is partially encrypted.

.zed archives are used as stand-alone or attached to e-mails with the help of a MS Outlook plugin. A variant, which is not covered here, can encrypt/decrypt MS Windows folders on the fly like ecryptfs.

In the spirit of academic and independent research this document provides a description of the file format and encryption algorithms for this encrypted file archive.

See the conventions section for conventions and acronyms used in this document.

Structure overview

The .zed file format is composed of several layers.

  • The main container is using the (MS-CFB), which is notably used by MS Office 97-2003 .doc files. It contains several streams:

    • Metadata stream: in OLE Property Set format (MS-OLEPS), contains 2 blobs in a specific Type-Length-Value (TLV) format:

      • _ctlfile: global archive properties and access list
        It is obfuscated by means of static-key AES encryption.
        The properties include archive initial filename and a global IV.
        A global encryption key is itself encrypted in each user entry.

      • _catalog: file list
        Contains each file metadata indexed with a 15-bytes identifier.
        Directories are supported.
        Full filename is encrypted using AES.
        File extension is (redundantly) stored in clear, and so are file metadata such as modification time.

    • Each file in the archive compressed with zlib and encrypted with the standard AES algorithm, in a separate stream.
      Several encryption schemes and key sizes are supported.
      The file stream is split in chunks of 512 bytes, individually encrypted.

    • Optional streams, contain additional metadata as well as pictures to display in the application background ("watermarks"). They are not discussed here.

Or as a diagram:

+----------------------------------------------------------------------------------------------------+ | .zed archive (MS-CBF) | | | | stream #1 stream #2 stream #3... | | +------------------------------+ +---------------------------+ +---------------------------+ | | | metadata (MS-OLEPS) | | encryption (AES) | | encryption (AES) | | | | | | 512-bytes chunks | | 512-bytes chunks | | | | +--------------------------+ | | | | | | | | | obfuscation (static key) | | | +-----------------------+ | | +-----------------------+ | | | | | +----------------------+ | | |-| compression (zlib) |-| |-| compression (zlib) |-| | | | | |_ctlfile (TLV) | | | | | | | | | | | ... | | | | +----------------------+ | | | | +---------------+ | | | | +---------------+ | | | | | +--------------------------+ | | | | file contents | | | | | | file contents | | | | | | | | | | | | | | | | | | | | | | +--------------------------+ | |-| +---------------+ |-| |-| +---------------+ |-| | | | | _catalog (TLV) | | | | | | | | | | | | | +--------------------------+ | | +-----------------------+ | | +-----------------------+ | | | +------------------------------+ +---------------------------+ +---------------------------+ | +----------------------------------------------------------------------------------------------------+ Encryption schemes

Several AES key sizes are supported, such as 128 and 256 bits.

The Cipher Block Chaining (CBC) block cipher mode of operation is used to decrypt multiple AES 16-byte blocks, which means an initialisation vector (IV) is stored in clear along with the ciphertext.

All filenames and file contents are encrypted using the same encryption mode, key and IV (e.g. if you remove and re-add a file in the archive, the resulting stream will be identical).

No cleartext padding is used during encryption; instead, several end-of-stream handlers are available, so the ciphertext has exactly the size of the cleartext (e.g. the size of the compressed file).

The following variants were identified in the 'encryption_mode' field.

STREAM

This is the end-of-stream handler for:

  • obfuscated metadata encrypted with static AES key
  • filenames and files in archives with 'encryption_mode' set to "AES-CBC-STREAM"
  • any AES ciphertext of size < 16 bytes, regardless of encryption mode

This end-of-stream handler is apparently specific to the .zed format, and applied when the cleartext's does not end on a 16-byte boundary ; in this case special processing is performed on the last partial 16-byte block.

The encryption and decryption phases are identical: let's assume the last partial block of cleartext (for encryption) or ciphertext (for decryption) was appended after all the complete 16-byte blocks of ciphertext:

  • the second-to-last block of the ciphertext is encrypted in AES-ECB mode (i.e. block cipher encryption only, without XORing with the IV)

  • then XOR-ed with the last partial block (hence truncated to the length of the partial block)

In either case, if the full ciphertext is less then one AES block (< 16 bytes), then the IV is used instead of the second-to-last block.

CTS

CTS or CipherText Stealing is the end-of-stream handler for:

  • filenames and files in archives with 'encryption_mode' set to "AES-CBC-CTS".
    • exception: if the size of the ciphertext is < 16 bytes, then "STREAM" is used instead.

It matches the CBC-CS3 variant as described in Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode.

Empty cleartext

Since empty filenames or metadata are invalid, and since all files are compressed (resulting in a minimum 8-byte zlib cleartext), no empty cleartext was encrypted in the archive.

metadata stream

It is named 05356861616161716149656b7a6565636e576a33317a7868304e63 (hexadecimal), i.e. the character with code 5 followed by '5haaaaqaIekzeecnWj31zxh0Nc' (ASCII).

The format used is OLE Property Set (MS-OLEPS).

It introduces 2 property names "_ctlfile" (index 3) and "_catalog" (index 4), and 2 instances of said properties each containing an application-specific VT_BLOB (type 0x0041).

_ctlfile: obfuscated global properties and access list

This subpart is stored under index 3 ("_ctlfile") of the MS-OLEPS metadata.

It consists of:

  • static delimiter 0765921A2A0774534752073361719300 (hexadecimal) followed by 0100 (hexadecimal) (18 bytes total)
  • 16-byte IV
  • ciphertext
  • 1 uint32be representing the length of all the above
  • static delimiter 0765921A2A0774534752073361719300 (hexadecimal) followed by "ZoneCentral (R)" (ASCII) and a NUL byte (32 bytes total)

The ciphertext is encrypted with AES-CBC "STREAM" mode using 128-bit static key 37F13CF81C780AF26B6A52654F794AEF (hexadecimal) and the prepended IV so as to obfuscate the access list. The ciphertext is continuous and not split in chunks (unlike files), even when it is larger than 512 bytes.

The decrypted text contain properties in a TLV format as described in _ctlfile TLV:

  • global archive properties as a 'fileprops' structure,

  • extra archive properties as a 'archive_extraprops' structure

  • users access list as a series of 'passworduser' and 'rsauser entries.

Archives may include "mandatory" users that cannot be removed. They are typically used to add an enterprise wide recovery RSA key to all archives. Extreme care must be taken to protect these key, as it can decrypt all past archives generated from within that company.

_catalog: file list

This subpart is stored under index 4 ("_catalog") of the MS-OLEPS metadata.

It contains a series of 'fileprops' TLV structures, one for each file or directory.

The file hierarchy can be reconstructed by checking the 'parent_id' field of each file entry. If 'parent_id' is 0 then the file is located at the top-level of the hierarchy, otherwise it's located under the directory with the matching 'file_id'.

TLV format

This format is a series of fields :

  • 4 bytes for Type (specified as a 4-bytes hexadecimal below)
  • 4 bytes for value Length (uint32be)
  • Value

Value semantics depend on its Type. It may contain an uint32be integer, a UTF-16LE string, a character sequence, or an inner TLV structure.

Unless otherwise noted, TLV structures appear once.

Some fields are optional and may not be present at all (e.g. 'archive_createdwith').

Some fields are unique within a structure (e.g. 'files_iv'), other may be repeated within a structure to form a list (e.g. 'fileprops' and 'passworduser').

The following top-level types that have been identified, and detailed in the next sections:

  • 80110600: fileprops, used for the file list as well as for the global archive properties
  • 001b0600: archive_extraprops
  • 80140600: accesslist

Some additional unidentified types may be present.

_ctlfile TLV
  • 80110600: fileprops (TLV structure): global archive properties
    • 00230400: archive_pathname (UTF-16LE string): initial archive filename (past versions also leaked the full pathname of the initial archive)
    • 80270200: encryption_mode (utf32be): 103 for "AES-CBC-STREAM", 104 for "AES-CBC-CTS"
    • 80260200: encryption_strength (utf32be): AES key size, in bytes (e.g. 32 means AES with a 256-bit key)
    • 80280500: files_iv (sequence of bytes): global IV for all filenames and file contents
  • 001b0600: archive_extraprops (TLV structure): additionnal archive properties (optional)
    • 00c40500: archive_creationtime (FILETIME): date and time when archive was initially created (optional)
    • 00c00400: archive_createdwith (UTF-16LE string): uuid-like structure describing the application that initialized the archive (optional)
      {00000188-1000-3CA8-8868-36F59DEFD14D} is Zed! Free 1.0.188.
  • 80140600: accesslist (TLV structure): describe the users, their key encryption and their permissions
    • 80610600: passworduser (TLV structure): user identified by password (0 or more)
    • 80620600: rsauser (TLV structure): user identified by RSA key (via file or PKCS#11 token) (0 or more)
    • Fields common to passworduser and rsauser:
      • 80710400: login (UTF-16LE string): user name
      • 80720300: login_md5 (sequence of bytes): used by the application to search for a user name
      • 807e0100: priv1 (uchar): user privileges; present and set to 1 when user is admin (optional)
      • 00830200: priv2 (uint32be): user privileges; present and set to 2 when user is admin, present and set to 5 when user is a marked as mandatory, e.g. for recovery keys (optional)
      • 80740500: files_key_ciphertext (sequence of bytes): the archive encryption key, itself encrypted
      • 00840500: user_creationtime (FILETIME): date and time when the user was added to the archive
    • passworduser-specific fields:
      • 80760500: pbe_salt (sequence of bytes): salt for PBE
      • 80770200: pbe_iter (uint32be): number of iterations for PBE
      • 80780200: pkcs12_hashfunc (uint32be): hash function used for PBE and PBA key derivation
      • 80790500: pba_checksum (sequence of bytes): password derived with PBA to check for password validity
      • 807a0500: pba_salt (sequence of bytes): salt for PBA
      • 807b0200: pba_iter (uint32be): number of iterations for PBA
    • rsauser-specific fields:
      • 807d0500: certificate (sequence of bytes): user X509 certificate in DER format
_catalog TLV
  • 80110600: fileprops (TLV structure): describe the archive files (0 or more)
    • 80300500: file_id (sequence of bytes): a 16-byte unique identifier
    • 80310400: filename_halfanon (UTF-16LE string): half-anonymized filename, e.g. File1.txt (leaking filename extension)
    • 00380500: filename_ciphertext (sequence of bytes): encrypted filename; may have a trailing NUL byte once decrypted
    • 80330500: file_size (uint64le): decompressed file size in bytes
    • 80340500: file_creationtime (FILETIME): file creation date and time
    • 80350500: file_lastwritetime (FILETIME): file last modification date and time
    • 80360500: file_lastaccesstime (FILETIME): file last access date and time
    • 00370500: parent_directory_id (sequence of bytes): file_id of the parent directory, 0 is top-level
    • 80320100: is_dir (uint32be): 1 if entry is directory (optional)
Decrypting the archive AES key rsauser

The user accessing the archive will be authenticated by comparing his/her X509 certificate with the one stored in the 'certificate' field using DER format.

The 'files_key_ciphertext' field is then decrypted using the PKCS#1 v1.5 encryption mechanism, with the private key that matches the user certificate.

passworduser

An intermediary user key, a user IV and an integrity checksum will be derived from the user password, using the deprecated PKCS#12 method as described at rfc7292 appendix B.

Note: this is not PKCS#5 (nor PBKDF1/PBKDF2), this is an incompatible method from PKCS#12 that notably does not use HMAC.

The 'pkcs12_hashfunc' field defines the underlying hash function. The following values have been identified:

  • 21: SHA-1
  • 22: SHA-256
PBA - Password-based authentication

The user accessing the archive will be authenticated by deriving an 8-byte sequence from his/her password.

The parameters for the derivation function are:

  • ID: 3
  • 'pba_salt': the salt, typically an 8-byte random sequence
  • 'pba_iter': the iteration count, typically 200000

The derivation is checked against 'pba_checksum'.

PBE - Password-based encryption

Once the user is identified, 2 new values are derived from the password with different parameters to produce the IV and the key decryption key, with the same hash function:

  • 'pbe_salt': the salt, typically an 8-bytes random sequence
  • 'pbe_iter': the iteration count, typically 100000

The parameters specific to user key are:

  • ID: 1
  • size: 32

The user key needs to be truncated to a length of 'encryption_strength', as specified in bytes in the archive properties.

The parameters specific to user IV are:

  • ID: 2
  • size: 16

Once the key decryption key and the IV are derived, 'files_key_ciphertext' is decrypted using AES CBC, with PKCS#7 padding.

Identifying file streams

The name of the MS-CFB stream is derived by shuffling the bytes from the 'file_id' field and then encoding the result as hexadecimal.

The reordering is:

Initial offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Shuffled offset: 3 2 1 0 5 4 7 6 8 9 10 11 12 13 14 15

The 16th byte is usually a NUL byte, hence the stream identifier is a 30-character-long string.

Decrypting files

The compressed stream is split in chunks of 512 bytes, each of them encrypted separately using AES CBS and the global archive encryption scheme. Decryption uses the global AES key (retrieved using the user credentials), and the global IV (retrieved from the deobfuscated archive metadata).

The IV for each chunk is computed by:

  • expressing the current chunk number as little endian on 16 bytes
  • XORing it with the global IV
  • encrypting with the global AES key in ECB mode (without IV).

Each chunk is an independent stream and the decryption process involves end-of-stream handling even if this is not the end of the actual file. This is particularly important for the CTS handler.

Note: this is not to be confused with CTR block cipher mode of operation with operates differently and requires a nonce.

Decompressing files

Compressed streams are zlib stream with default compression options and can be decompressed following the zlib format.

Test cases

Excluded for brevity, cf. https://www.beuc.net/zed/#test-cases.

Conventions and references Feedback

Feel free to send comments at beuc@beuc.net. If you have .zed files that you think are not covered by this document, please send them as well (replace sensitive files with other ones). The author's GPG key can be found at 8FF1CB6E8D89059F.

Copyright (C) 2017 Sylvain Beucler

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

Beuc's Blog https://blog.beuc.net/tags/planet_debian/ pages tagged planet debian

dot-zed archive file format

Planet Debian - Dje, 10/09/2017 - 3:50md

TL,DR: I reverse-engineered the .zed encrypted archive format.
Following a clean-room design, I'm providing a description that can be implemented by a third-party.
Interested?

(reference version at: https://www.beuc.net/zed/)

.zed archive file format Introduction

Archives with the .zed extension are conceptually similar to an encrypted .zip file.

In addition to a specific format, .zed files support multiple users: files are encrypted using the archive master key, which itself is encrypted for each user and/or authentication method (password, RSA key through certificate or PKCS#11 token). Metadata such as filenames is partially encrypted.

.zed archives are used as stand-alone or attached to e-mails with the help of a MS Outlook plugin. A variant, which is not covered here, can encrypt/decrypt MS Windows folders on the fly like ecryptfs.

In the spirit of academic and independent research this document provides a description of the file format and encryption algorithms for this encrypted file archive.

See the conventions section for conventions and acronyms used in this document.

Structure overview

The .zed file format is composed of several layers.

  • The main container is using the (MS-CFB), which is notably used by MS Office 97-2003 .doc files. It contains several streams:

    • Metadata stream: in OLE Property Set format (MS-OLEPS), contains 2 blobs in a specific Type-Length-Value (TLV) format:

      • _ctlfile: global archive properties and access list
        It is obfuscated by means of static-key AES encryption.
        The properties include archive initial filename and a global IV.
        A global encryption key is itself encrypted in each user entry.

      • _catalog: file list
        Contains each file metadata indexed with a 15-bytes identifier.
        Directories are supported.
        Full filename is encrypted using AES.
        File extension is (redundantly) stored in clear, and so are file metadata such as modification time.

    • Each file in the archive compressed with zlib and encrypted with the standard AES algorithm, in a separate stream.
      Several encryption schemes and key sizes are supported.
      The file stream is split in chunks of 512 bytes, individually encrypted.

    • Optional streams, contain additional metadata as well as pictures to display in the application background ("watermarks"). They are not discussed here.

Or as a diagram:

+----------------------------------------------------------------------------------------------------+ | .zed archive (MS-CBF) | | | | stream #1 stream #2 stream #3... | | +------------------------------+ +---------------------------+ +---------------------------+ | | | metadata (MS-OLEPS) | | encryption (AES) | | encryption (AES) | | | | | | 512-bytes chunks | | 512-bytes chunks | | | | +--------------------------+ | | | | | | | | | obfuscation (static key) | | | +-----------------------+ | | +-----------------------+ | | | | | +----------------------+ | | |-| compression (zlib) |-| |-| compression (zlib) |-| | | | | |_ctlfile (TLV) | | | | | | | | | | | ... | | | | +----------------------+ | | | | +---------------+ | | | | +---------------+ | | | | | +--------------------------+ | | | | file contents | | | | | | file contents | | | | | | | | | | | | | | | | | | | | | | +--------------------------+ | |-| +---------------+ |-| |-| +---------------+ |-| | | | | _catalog (TLV) | | | | | | | | | | | | | +--------------------------+ | | +-----------------------+ | | +-----------------------+ | | | +------------------------------+ +---------------------------+ +---------------------------+ | +----------------------------------------------------------------------------------------------------+ Encryption schemes

Several AES key sizes are supported, such as 128 and 256 bits.

The Cipher Block Chaining (CBC) block cipher mode of operation is used to decrypt multiple AES 16-byte blocks, which means an initialisation vector (IV) is stored in clear along with the ciphertext.

All filenames and file contents are encrypted using the same encryption mode, key and IV (e.g. if you remove and re-add a file in the archive, the resulting stream will be identical).

No cleartext padding is used during encryption; instead, several end-of-stream handlers are available, so the ciphertext has exactly the size of the cleartext (e.g. the size of the compressed file).

The following variants were identified in the 'encryption_mode' field.

STREAM

This is the end-of-stream handler for:

  • obfuscated metadata encrypted with static AES key
  • filenames and files in archives with 'encryption_mode' set to "AES-CBC-STREAM"
  • any AES ciphertext of size < 16 bytes, regardless of encryption mode

This end-of-stream handler is apparently specific to the .zed format, and applied when the cleartext's does not end on a 16-byte boundary ; in this case special processing is performed on the last partial 16-byte block.

The encryption and decryption phases are identical: let's assume the last partial block of cleartext (for encryption) or ciphertext (for decryption) was appended after all the complete 16-byte blocks of ciphertext:

  • the second-to-last block of the ciphertext is encrypted in AES-ECB mode (i.e. block cipher encryption only, without XORing with the IV)

  • then XOR-ed with the last partial block (hence truncated to the length of the partial block)

In either case, if the full ciphertext is less then one AES block (< 16 bytes), then the IV is used instead of the second-to-last block.

CTS

CTS or CipherText Stealing is the end-of-stream handler for:

  • filenames and files in archives with 'encryption_mode' set to "AES-CBC-CTS".
    • exception: if the size of the ciphertext is < 16 bytes, then "STREAM" is used instead.

It matches the CBC-CS3 variant as described in Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode.

Empty cleartext

Since empty filenames or metadata are invalid, and since all files are compressed (resulting in a minimum 8-byte zlib cleartext), no empty cleartext was encrypted in the archive.

metadata stream

It is named 05356861616161716149656b7a6565636e576a33317a7868304e63 (hexadecimal), i.e. the character with code 5 followed by '5haaaaqaIekzeecnWj31zxh0Nc' (ASCII).

The format used is OLE Property Set (MS-OLEPS).

It introduces 2 property names "_ctlfile" (index 3) and "_catalog" (index 4), and 2 instances of said properties each containing an application-specific VT_BLOB (type 0x0041).

_ctlfile: obfuscated global properties and access list

This subpart is stored under index 3 ("_ctlfile") of the MS-OLEPS metadata.

It consists of:

  • static delimiter 0765921A2A0774534752073361719300 (hexadecimal) followed by 0100 (hexadecimal) (18 bytes total)
  • 16-byte IV
  • ciphertext
  • 1 uint32be representing the length of all the above
  • static delimiter 0765921A2A0774534752073361719300 (hexadecimal) followed by "ZoneCentral (R)" (ASCII) and a NUL byte (32 bytes total)

The ciphertext is encrypted with AES-CBC "STREAM" mode using 128-bit static key 37F13CF81C780AF26B6A52654F794AEF (hexadecimal) and the prepended IV so as to obfuscate the access list. The ciphertext is continuous and not split in chunks (unlike files), even when it is larger than 512 bytes.

The decrypted text contain properties in a TLV format as described in _ctlfile TLV:

  • global archive properties as a 'fileprops' structure,

  • extra archive properties as a 'archive_extraprops' structure

  • users access list as a series of 'passworduser' and 'rsauser entries.

Archives may include "mandatory" users that cannot be removed. They are typically used to add an enterprise wide recovery RSA key to all archives. Extreme care must be taken to protect these key, as it can decrypt all past archives generated from within that company.

_catalog: file list

This subpart is stored under index 4 ("_catalog") of the MS-OLEPS metadata.

It contains a series of 'fileprops' TLV structures, one for each file or directory.

The file hierarchy can be reconstructed by checking the 'parent_id' field of each file entry. If 'parent_id' is 0 then the file is located at the top-level of the hierarchy, otherwise it's located under the directory with the matching 'file_id'.

TLV format

This format is a series of fields :

  • 4 bytes for Type (specified as a 4-bytes hexadecimal below)
  • 4 bytes for value Length (uint32be)
  • Value

Value semantics depend on its Type. It may contain an uint32be integer, a UTF-16LE string, a character sequence, or an inner TLV structure.

Unless otherwise noted, TLV structures appear once.

Some fields are optional and may not be present at all (e.g. 'archive_createdwith').

Some fields are unique within a structure (e.g. 'files_iv'), other may be repeated within a structure to form a list (e.g. 'fileprops' and 'passworduser').

The following top-level types that have been identified, and detailed in the next sections:

  • 80110600: fileprops, used for the file list as well as for the global archive properties
  • 001b0600: archive_extraprops
  • 80140600: accesslist

Some additional unidentified types may be present.

_ctlfile TLV
  • 80110600: fileprops (TLV structure): global archive properties
    • 00230400: archive_pathname (UTF-16LE string): initial archive filename (past versions also leaked the full pathname of the initial archive)
    • 80270200: encryption_mode (utf32be): 103 for "AES-CBC-STREAM", 104 for "AES-CBC-CTS"
    • 80260200: encryption_strength (utf32be): AES key size, in bytes (e.g. 32 means AES with a 256-bit key)
    • 80280500: files_iv (sequence of bytes): global IV for all filenames and file contents
  • 001b0600: archive_extraprops (TLV structure): additionnal archive properties (optional)
    • 00c40500: archive_creationtime (FILETIME): date and time when archive was initially created (optional)
    • 00c00400: archive_createdwith (UTF-16LE string): uuid-like structure describing the application that initialized the archive (optional)
      {00000188-1000-3CA8-8868-36F59DEFD14D} is Zed! Free 1.0.188.
  • 80140600: accesslist (TLV structure): describe the users, their key encryption and their permissions
    • 80610600: passworduser (TLV structure): user identified by password (0 or more)
    • 80620600: rsauser (TLV structure): user identified by RSA key (via file or PKCS#11 token) (0 or more)
    • Fields common to passworduser and rsauser:
      • 80710400: login (UTF-16LE string): user name
      • 80720300: login_md5 (sequence of bytes): used by the application to search for a user name
      • 807e0100: priv1 (uchar): user privileges; present and set to 1 when user is admin (optional)
      • 00830200: priv2 (uint32be): user privileges; present and set to 2 when user is admin, present and set to 5 when user is a marked as mandatory, e.g. for recovery keys (optional)
      • 80740500: files_key_ciphertext (sequence of bytes): the archive encryption key, itself encrypted
      • 00840500: user_creationtime (FILETIME): date and time when the user was added to the archive
    • passworduser-specific fields:
      • 80760500: pbe_salt (sequence of bytes): salt for PBE
      • 80770200: pbe_iter (uint32be): number of iterations for PBE
      • 80780200: pkcs12_hashfunc (uint32be): hash function used for PBE and PBA key derivation
      • 80790500: pba_checksum (sequence of bytes): password derived with PBA to check for password validity
      • 807a0500: pba_salt (sequence of bytes): salt for PBA
      • 807b0200: pba_iter (uint32be): number of iterations for PBA
    • rsauser-specific fields:
      • 807d0500: certificate (sequence of bytes): user X509 certificate in DER format
_catalog TLV
  • 80110600: fileprops (TLV structure): describe the archive files (0 or more)
    • 80300500: file_id (sequence of bytes): a 16-byte unique identifier
    • 80310400: filename_halfanon (UTF-16LE string): half-anonymized filename, e.g. File1.txt (leaking filename extension)
    • 00380500: filename_ciphertext (sequence of bytes): encrypted filename; may have a trailing NUL byte once decrypted
    • 80330500: file_size (uint64le): decompressed file size in bytes
    • 80340500: file_creationtime (FILETIME): file creation date and time
    • 80350500: file_lastwritetime (FILETIME): file last modification date and time
    • 80360500: file_lastaccesstime (FILETIME): file last access date and time
    • 00370500: parent_directory_id (sequence of bytes): file_id of the parent directory, 0 is top-level
    • 80320100: is_dir (uint32be): 1 if entry is directory (optional)
Decrypting the archive AES key rsauser

The user accessing the archive will be authenticated by comparing his/her X509 certificate with the one stored in the 'certificate' field using DER format.

The 'files_key_ciphertext' field is then decrypted using the PKCS#1 v1.5 encryption mechanism, with the private key that matches the user certificate.

passworduser

An intermediary user key, a user IV and an integrity checksum will be derived from the user password, using the deprecated PKCS#12 method as described at rfc7292 appendix B.

Note: this is not PKCS#5 (nor PBKDF1/PBKDF2), this is an incompatible method from PKCS#12 that notably does not use HMAC.

The 'pkcs12_hashfunc' field defines the underlying hash function. The following values have been identified:

  • 21: SHA-1
  • 22: SHA-256
PBA - Password-based authentication

The user accessing the archive will be authenticated by deriving an 8-byte sequence from his/her password.

The parameters for the derivation function are:

  • ID: 3
  • 'pba_salt': the salt, typically an 8-byte random sequence
  • 'pba_iter': the iteration count, typically 200000

The derivation is checked against 'pba_checksum'.

PBE - Password-based encryption

Once the user is identified, 2 new values are derived from the password with different parameters to produce the IV and the key decryption key, with the same hash function:

  • 'pbe_salt': the salt, typically an 8-bytes random sequence
  • 'pbe_iter': the iteration count, typically 100000

The parameters specific to user key are:

  • ID: 1
  • size: 32

The user key needs to be truncated to a length of 'encryption_strength', as specified in bytes in the archive properties.

The parameters specific to user IV are:

  • ID: 2
  • size: 16

Once the key decryption key and the IV are derived, 'files_key_ciphertext' is decrypted using AES CBC, with PKCS#7 padding.

Identifying file streams

The name of the MS-CFB stream is derived by shuffling the bytes from the 'file_id' field and then encoding the result as hexadecimal.

The reordering is:

Initial offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Shuffled offset: 3 2 1 0 5 4 7 6 8 9 10 11 12 13 14 15

The 16th byte is usually a NUL byte, hence the stream identifier is a 30-character-long string.

Decrypting files

The compressed stream is split in chunks of 512 bytes, each of them encrypted separately using AES CBS and the global archive encryption scheme. Decryption uses the global AES key (retrieved using the user credentials), and the global IV (retrieved from the deobfuscated archive metadata).

The IV for each chunk is computed by:

  • expressing the current chunk number as little endian on 16 bytes
  • XORing it with the global IV
  • encrypting with the global AES key in ECB mode (without IV).

Each chunk is an independent stream and the decryption process involves end-of-stream handling even if this is not the end of the actual file. This is particularly important for the CTS handler.

Note: this is not to be confused with CTR block cipher mode of operation with operates differently and requires a nonce.

Decompressing files

Compressed streams are zlib stream with default compression options and can be decompressed following the zlib format.

Test cases

Excluded for brevity, cf. https://www.beuc.net/zed/#test-cases.

Conventions and references Feedback

Feel free to send comments at beuc@beuc.net. If you have .zed files that you think are not covered by this document, please send them as well (replace sensitive files with other ones). The author's GPG key can be found at 8FF1CB6E8D89059F.

Copyright (C) 2017 Sylvain Beucler

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

Beuc's Blog http://blog.beuc.net/tags/planet_debian/ pages tagged planet debian

Summary of the discussion on off-line keys.

Planet Debian - Dje, 10/09/2017 - 2:06md

Last month, there has been an interesting discussion about off-line GnuPG keys and their storage systems on the debian-project@l.d.o mailing list. I tried to summarise it in the Debian wiki, in particular by creating two new pages.

Charles Plessy http://charles.plessy.org/Debian/planet/ Planet

Faqet

Subscribe to AlbLinux agreguesi

Alblinux.net mundësohet nga Drupal.