From: Sebastian Moeller <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] security guidelines for home routers
Date: Mon, 26 Nov 2018 19:24:54 +0100 [thread overview]
Message-ID: <6F8CDBFF-8B8A-4B6B-BCE9-918A69354626@gmx.de> (raw)
In-Reply-To: <CAA93jw54urN1Gh731zg0MGsyCiWPOLNa2p__GXZMJd=ODMWLiw@mail.gmail.com>
Hi Dave,
neither the openwrt folks (see https://openwrt.org) nor the chaos computer club of germany (see German: https://www.ccc.de/en/updates/2018/risikorouter, machinenglish: https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=https%3A%2F%2Fwww.ccc.de%2Fen%2Fupdates%2F2018%2Frisikorouter&edit-text=) seem to be fully convinced.
Personally I believe this is a step in the right direction, even though hopefully just a first step.
Openwrt and CCC mainly critizise:
"The Chaos Computer Club (CCC) and OpenWrt took part in multiple review and discussion rounds with the Bundesamt für Sicherheit in der Informationstechnik (BSI) and representatives of multiple device vendors and network operators. These are our two main demands:
1) Vendors have to inform customer before buying the product for all devices being sold in Germany, how long the device will get security updates in case problems are found.
2) The customer must have the possibility to install custom software on their devices, to have the possibility to fix security problems even after the official vendor support ended."
I believe that 1) is currently supposed to be posted on a web-site so will not be effortlessly visible at the point of sale in a store.
And 2) basically is a complaint that there is a weak MAY clause for guaranteeing that 3rd party firmware like openwrt is installable. I think this was weakened on purpose by the DOCSIS-ISPs which seem to have zero interest for 3rd party firmwares for cable-modems/routers. (I would not be amazed if cable labs would actually rule something like this out per contract, but I have zero evidence for that hypothesis).
> On Nov 26, 2018, at 19:05, Dave Taht <dave.taht@gmail.com> wrote:
>
> I only briefly scanned this, but I did find some things that made me
> happy. Still, What happens after end of life?
>
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf;jsessionid=01F54E80B004E9BFB194DBC00DE9B961.2_cid360?__blob=publicationFile&v=2
>
> "To be able to react to newly appearing exploits of soft- or hardware
> vulnerabilities of the router or any of its components the router MUST
> have a functionality to update the firmware (operating system and
> applications) using a firmware package. The router MUST allow the
> end-user to fully control such a firmware update and determine to
> initiate an online update (router retrieves firmware package from the
> Internet (WAN interface)) and/ or manually update the firmware through
> the configuration interface (user provides firmware package) described
> in Section 4.1: Configuration and Information."
>
> The router SHOULD offer an option to automatically retrieve security
> relevant firmware updates from a trustworthy source over the Internet
> (WAN interface). If the router offers this functionality it SHOULD be
> activated by default, but MUST be possible for the end-user to
> deactivate it when using customized settings. In both scenarios
> (manual and automated update) the firmware update function of the
> router MUST check the authenticity of the firmware package (file)
> before it is installed on the router. This SHOULD be done by a digital
> signature that is applied to the firmware package by the manufacturer
> and checked by the router itself. For this purpose only signature
> schemes in accordance to [SOG-IS] Section 5.2: Digital Signatures MUST
> be used. The router MUST NOT automatically install any unsigned
> firmware. The router MAY allow the installation of unsigned firmware
> (i.e. custom firmware) IF a meaningful warning message has been shown
> to the authenticated end-user and the end-user accepts the
> installation of the unsigned firmware.
>
> the manufacturer of the router MUST provide information on how long
> firmware updates fixing common vulnerabilities and exposures that have
> a high severity (i.e. a CVSS combined score higher than 6.0 according
> to the Common Vulnerability Scoring System3 assigned to the specific
> device or a component used by the device) will be made available. This
> information SHOULD be available on the manufacturer website.
> Additionally it MAY be made available on the router configuration
> interface described in Section 4.1.2: Providing Information. The
> manufacturer MUST provide information if the router has reached the
> End of its Support (EoS) and will not receive firmware updates by the
> manufacturer anymore. This information (EoS) MUST be made available on
> the router configuration as described in Section 4.1.2: Providing
> Information. The manufacturer MUST provide firmware updates to fix
> common vulnerabilities and exposures of a high severity without
> culpable delay (without undue delay) after the manufacturer obtains
> knowledge
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
next prev parent reply other threads:[~2018-11-26 18:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-26 18:05 Dave Taht
2018-11-26 18:24 ` Sebastian Moeller [this message]
2018-11-26 18:35 ` Mikael Abrahamsson
2018-11-26 22:13 ` Sebastian Moeller
2018-11-27 11:03 ` Mikael Abrahamsson
2018-11-27 11:52 ` Sebastian Moeller
2018-11-27 13:34 ` Mikael Abrahamsson
2018-11-28 13:49 ` Sebastian Moeller
2018-11-27 18:23 ` valdis.kletnieks
2018-11-26 18:40 ` Dave Taht
2018-11-26 21:05 ` Toke Høiland-Jørgensen
2018-11-26 22:28 ` Sebastian Moeller
2018-11-27 0:29 ` David P. Reed
2018-11-27 11:07 ` Mikael Abrahamsson
2018-11-27 11:17 ` Jonathan Morton
2018-11-28 9:17 ` Michael Richardson
2018-11-28 9:14 ` Michael Richardson
2018-11-28 19:10 ` David P. Reed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6F8CDBFF-8B8A-4B6B-BCE9-918A69354626@gmx.de \
--to=moeller0@gmx.de \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox