When introducing ubus reload support, ubus initialization was moved
to the service level instead of being carried out when adding a BSS
configuration. While this works when using wpa_supplicant in that way,
it breaks the ability to run wpa_supplicant on the command line, eg.
for debugging purposes.
Fix that by re-introducing ubus context intialization when adding
configuration.
Reported-by: @PolynomialDivision https://github.com/openwrt/openwrt/pull/2417
Fixes: 60fb4c92b6 ("hostapd: add ubus reload")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
c888e17e06 ("hostapd: manage instances via procd instead of pidfile")
added procd support for managing hostapd and wpa_supplicant daemons
but at the same time limited wiphy names to 'phy*'.
This brings back initial behaviour (introduced in 60fb4c92b6 ("hostapd:
add ubus reload") and makes procd manage daemons for any wiphy device
found in '/sys/class/ieee80211'.
CC: Felix Fietkau <nbd@nbd.name>
CC: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
The $(space) definition in the hostapd Makefile ceased to work with
GNU Make 4.3 and later, leading to syntax errors in the generated
Kconfig files.
Drop the superfluous redefinition and reuse the working $(space)
declaration from rules.mk to fix this issue.
Fixes: GH#2713
Ref: https://github.com/openwrt/openwrt/pull/2713#issuecomment-583722469
Reported-by: Karel Kočí <cynerd@email.cz>
Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
Tested-by: Shaleen Jain <shaleen@jain.sh>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Currently, it is very cumbersome for a user to connect to a WPA-Enterprise
based network securely because the RADIUS server's CA certificate must first be
extracted from the EAPOL handshake using tcpdump or other methods before it can
be pinned using the ca_cert(2) fields. To make this process easier and more
secure (combined with changes in openwrt/openwrt#2654), this commit adds
support for validating against the built-in CA bundle when the ca-bundle
package is installed. Related LuCI changes in openwrt/luci#3513.
Signed-off-by: David Lam <david@thedavid.net>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Allows dtim_period to be configurable, the default is from hostapd.
Adds additional regulatory tunables for power constraint and spectrum
managment.
Signed-off-by: Kyle Copperfield <kmcopper@danwin1210.me>
The wpa_supplicant supports certificate subject validation via the
subject match(2) and altsubject_match(2) fields. domain_match(2) and
domain_suffix_match(2) fields are also supported for advanced matches.
This validation is especially important when connecting to access
points that use PAP as the Phase 2 authentication type. Without proper
validation, the user's password can be transmitted to a rogue access
point in plaintext without the user's knowledge. Most organizations
already require these attributes to be included to ensure that the
connection from the STA and the AP is secure. Includes LuCI changes via
openwrt/luci#3444.
From the documentation:
subject_match - Constraint for server certificate subject. This substring
is matched against the subject of the authentication server certificate.
If this string is set, the server sertificate is only accepted if it
contains this string in the subject. The subject string is in following
format: /C=US/ST=CA/L=San Francisco/CN=Test AS/emailAddress=as
.example.com
subject_match2 - Constraint for server certificate subject. This field is
like subject_match, but used for phase 2 (inside EAP-TTLS/PEAP/FAST
tunnel) authentication.
altsubject_match - Constraint for server certificate alt. subject.
Semicolon separated string of entries to be matched against the
alternative subject name of the authentication server certificate. If
this string is set, the server sertificate is only accepted if it
contains one of the entries in an alternative subject name extension.
altSubjectName string is in following format: TYPE:VALUE Example:
EMAIL:server@example.com Example:
DNS:server.example.com;DNS:server2.example.com Following types are
supported: EMAIL, DNS, URI
altsubject_match2 - Constraint for server certificate alt. subject. This
field is like altsubject_match, but used for phase 2 (inside
EAP-TTLS/PEAP/FAST tunnel) authentication.
domain_match - Constraint for server domain name. If set, this FQDN is
used as a full match requirement for the
server certificate in SubjectAltName dNSName element(s). If a
matching dNSName is found, this constraint is met. If no dNSName
values are present, this constraint is matched against SubjectName CN
using same full match comparison. This behavior is similar to
domain_suffix_match, but has the requirement of a full match, i.e.,
no subdomains or wildcard matches are allowed. Case-insensitive
comparison is used, so "Example.com" matches "example.com", but would
not match "test.Example.com". More than one match string can be
provided by using semicolons to
separate the strings (e.g., example.org;example.com). When multiple
strings are specified, a match with any one of the values is considered
a sufficient match for the certificate, i.e., the conditions are ORed
together.
domain_match2 - Constraint for server domain name. This field is like
domain_match, but used for phase 2 (inside EAP-TTLS/PEAP/FAST tunnel)
authentication.
domain_suffix_match - Constraint for server domain name. If set, this
FQDN is used as a suffix match requirement for the AAA server
certificate in SubjectAltName dNSName element(s). If a matching dNSName
is found, this constraint is met. If no dNSName values are present,
this constraint is matched against SubjectName CN using same suffix
match comparison. Suffix match here means that the host/domain name is
compared one label at a time starting from the top-level domain and all
the labels in domain_suffix_match shall be included in the certificate.
The certificate may include additional sub-level labels in addition to
the required labels. More than one match string can be provided by using
semicolons to separate the strings (e.g., example.org;example.com).
When multiple strings are specified, a match with any one of the values
is considered a sufficient match for the certificate, i.e., the
conditions are ORed together. For example,
domain_suffix_match=example.com would match test.example.com but would
not match test-example.com. This field is like domain_match, but used
for phase 2 (inside EAP-TTLS/PEAP/FAST tunnel) authentication.
domain_suffix_match2 - Constraint for server domain name. This field is
like domain_suffix_match, but used for phase 2 (inside
EAP-TTLS/PEAP/FAST tunnel) authentication.
Signed-off-by: David Lam <david@thedavid.net>
This activates PIE ASLR support by default when the regular option is
selected.
This increases the binary size by 26% uncompressed and 16% compressed
on MIPS BE.
old:
460,933 /usr/sbin/wpad
283,891 wpad-basic_2019-08-08-ca8c2bd2-1_mips_24kc.ipk
new:
584,508 /usr/sbin/wpad
330,281 wpad-basic_2019-08-08-ca8c2bd2-1_mips_24kc.ipk
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Petr Štetiar <ynezz@true.cz>
Add ubus interface to hostapd and wpa_supplicant to allow dynamically
reloading wiface configuration without having to restart the hostapd
process.
As a consequence, both hostapd and wpa_supplicant are now started
persistently on boot for each wifi device in the system and then
receive ubus calls adding, modifying or removing interface
configuration.
At a later stage it would be desirable to reduce the services to one
single instance managing all radios.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The size of the ipkgs increase a bit (between 0.7% and 1.1%):
old 2019-04-21 (2.8):
288264 wpad-basic_2019-04-21-63962824-1_mipsel_24kc.ipk
256188 wpad-mini_2019-04-21-63962824-1_mipsel_24kc.ipk
427475 wpad-openssl_2019-04-21-63962824-1_mipsel_24kc.ipk
423071 wpad-wolfssl_2019-04-21-63962824-1_mipsel_24kc.ipk
new 2019-08-08 (2.9):
290217 wpad-basic_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk
258745 wpad-mini_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk
431732 wpad-openssl_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk
427641 wpad-wolfssl_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This also syncs the configuration files with the default configuration
files, but no extra options are activated or deactivated.
The mesh patches were partially merged into hostapd 2.8, the remaining
patches were extracted from patchwork and are now applied by OpenWrt.
The patches still have open questions which are not fixed by the author.
They were taken from this page:
https://patchwork.ozlabs.org/project/hostap/list/?series=62725&state=*
The changes in 007-mesh-apply-channel-attributes-before-running-Mesh.patch
where first applied to hostapd, but later reverted in hostapd commit
3e949655ccc5 because they caused memory leaks.
The size of the ipkgs increase a bit (between 1.3% and 2.3%):
old 2018-12-02 (2.7):
283337 wpad-basic_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
252857 wpad-mini_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
417473 wpad-openssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
415105 wpad-wolfssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
new 2019-04-21 (2.8):
288264 wpad-basic_2019-04-21-63962824-1_mipsel_24kc.ipk
256188 wpad-mini_2019-04-21-63962824-1_mipsel_24kc.ipk
427475 wpad-openssl_2019-04-21-63962824-1_mipsel_24kc.ipk
423071 wpad-wolfssl_2019-04-21-63962824-1_mipsel_24kc.ipk
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
For AP mode, OpenWrt automatically sets ieee80211w to either 1 or 2, depending
on whether the encryption is set to sae-mixed, or sae/owe/eap suite-b.
Mirror the same defaults for client mode connections, in order to allow an
OpenWrt station to associate to an OpenWrt ap with SAE, OWE or Suite-B encryption
without the need to manually specify "option ieee80211w" on the station.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This changes fixes the generation of the wpa_supplicant client configuration
in WPA3 OWE client mode. Instead of incorrectly emitting key_mgmt=NONE, use
the proper key_mgmt=OWE setting instead.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This commit will activate CONFIG_IEEE80211W for all, but the mini
variant when at least one driver supports it. This will add ieee80211w
support for the mesh variant for example.
Fixes: FS#2397
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This changes the default PKG_BUILD_DIR to take BUILD_VARIANT into
account (if set), so that packages do not need to manually override
PKG_BUILD_DIR just to handle variants.
This also updates most base packages with variants to use the updated
default PKG_BUILD_DIR.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Support to disable the timestamp check for certificates in
wpa_supplicant (Useful for devices without RTC that cannot
reliably get the real date/time) has been accepted in the
upstream hostapd. It's implemented in wpa_supplicant as a
per-AP flag tls_disable_time_checks=[0|1].
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
EAP-pwd missing commit validation
Published: April 10, 2019
Identifiers:
- CVE-2019-9497 (EAP-pwd server not checking for reflection attack)
- CVE-2019-9498 (EAP-pwd server missing commit validation for
scalar/element)
- CVE-2019-9499 (EAP-pwd peer missing commit validation for
scalar/element)
Latest version available from: https://w1.fi/security/2019-4/
Vulnerability
EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP
peer) was discovered not to validate the received scalar and element
values in EAP-pwd-Commit messages properly. This could result in attacks
that would be able to complete EAP-pwd authentication exchange without
the attacker having to know the used password.
A reflection attack is possible against the EAP-pwd server since the
hostapd EAP server did not verify that the EAP-pwd-Commit contains
scalar/element values that differ from the ones the server sent out
itself. This allows the attacker to complete EAP-pwd authentication
without knowing the password, but this does not result in the attacker
being able to derive the session key (MSK), i.e., the attacker would not
be able to complete the following key exchange (e.g., 4-way handshake in
RSN/WPA).
An attack using invalid scalar/element values is possible against both
the EAP-pwd server and peer since hostapd and wpa_supplicant did not
validate these values in the received EAP-pwd-Commit messages. If the
used crypto library does not implement additional checks for the element
(EC point), this could result in attacks where the attacker could use a
specially crafted commit message values to manipulate the exchange to
result in deriving a session key value from a very small set of possible
values. This could further be used to attack the EAP-pwd server in a
practical manner. An attack against the EAP-pwd peer is slightly more
complex, but still consider practical. These invalid scalar/element
attacks could result in the attacker being able to complete
authentication and learn the session key and MSK to allow the key
exchange to be completed as well, i.e., the attacker gaining access to
the network in case of the attack against the EAP server or the attacker
being able to operate a rogue AP in case of the attack against the EAP
peer.
While similar attacks might be applicable against SAE, it should be
noted that the SAE implementation in hostapd and wpa_supplicant does
have the validation steps that were missing from the EAP-pwd
implementation and as such, these attacks do not apply to the current
SAE implementation. Old versions of wpa_supplicant/hostapd did not
include the reflection attack check in the SAE implementation, though,
since that was added in June 2015 for v2.5 (commit 6a58444d27fd 'SAE:
Verify that own/peer commit-scalar and COMMIT-ELEMENT are different').
Vulnerable versions/configurations
All hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build
configuration and EAP-pwd being enabled in the runtime configuration)
are vulnerable against the reflection attack.
All wpa_supplicant and hostapd versions with EAP-pwd support
(CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled
in the runtime configuration) are vulnerable against the invalid
scalar/element attack when built against a crypto library that does not
have an explicit validation step on imported EC points. The following
list indicates which cases are vulnerable/not vulnerable:
- OpenSSL v1.0.2 or older: vulnerable
- OpenSSL v1.1.0 or newer: not vulnerable
- BoringSSL with commit 38feb990a183 ('Require that EC points are on the
curve.') from September 2015: not vulnerable
- BoringSSL without commit 38feb990a183: vulnerable
- LibreSSL: vulnerable
- wolfssl: vulnerable
Acknowledgments
Thanks to Mathy Vanhoef (New York University Abu Dhabi) for discovering
and reporting the issues and for proposing changes to address them in
the implementation.
Possible mitigation steps
- Merge the following commits to wpa_supplicant/hostapd and rebuild:
CVE-2019-9497:
EAP-pwd server: Detect reflection attacks
CVE-2019-9498:
EAP-pwd server: Verify received scalar and element
EAP-pwd: Check element x,y coordinates explicitly
CVE-2019-9499:
EAP-pwd client: Verify received scalar and element
EAP-pwd: Check element x,y coordinates explicitly
These patches are available from https://w1.fi/security/2019-4/
- Update to wpa_supplicant/hostapd v2.8 or newer, once available
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
hostapd: fix SAE confirm missing state validation
Published: April 10, 2019
Identifiers:
- CVE-2019-9496 (SAE confirm missing state validation in hostapd/AP)
Latest version available from: https://w1.fi/security/2019-3/
Vulnerability
When hostapd is used to operate an access point with SAE (Simultaneous
Authentication of Equals; also known as WPA3-Personal), an invalid
authentication sequence could result in the hostapd process terminating
due to a NULL pointer dereference when processing SAE confirm
message. This was caused by missing state validation steps when
processing the SAE confirm message in hostapd/AP mode.
Similar cases against the wpa_supplicant SAE station implementation had
already been tested by the hwsim test cases, but those sequences did not
trigger this specific code path in AP mode which is why the issue was
not discovered earlier.
An attacker in radio range of an access point using hostapd in SAE
configuration could use this issue to perform a denial of service attack
by forcing the hostapd process to terminate.
Vulnerable versions/configurations
All hostapd versions with SAE support (CONFIG_SAE=y in the build
configuration and SAE being enabled in the runtime configuration).
Possible mitigation steps
- Merge the following commit to hostapd and rebuild:
SAE: Fix confirm message validation in error cases
These patches are available from https://w1.fi/security/2019-3/
- Update to hostapd v2.8 or newer, once available
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
EAP-pwd side-channel attack
Published: April 10, 2019
Identifiers:
- CVE-2019-9495 (cache attack against EAP-pwd)
Latest version available from: https://w1.fi/security/2019-2/
Vulnerability
Number of potential side channel attacks were recently discovered in the
SAE implementations used by both hostapd and wpa_supplicant (see
security advisory 2019-1 and VU#871675). EAP-pwd uses a similar design
for deriving PWE from the password and while a specific attack against
EAP-pwd is not yet known to be tested, there is no reason to believe
that the EAP-pwd implementation would be immune against the type of
cache attack that was identified for the SAE implementation. Since the
EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP
peer) does not support MODP groups, the timing attack described against
SAE is not applicable for the EAP-pwd implementation.
A novel cache-based attack against SAE handshake would likely be
applicable against the EAP-pwd implementation. Even though the
wpa_supplicant/hostapd PWE derivation iteration for EAP-pwd has
protections against timing attacks, this new cache-based attack might
enable an attacker to determine which code branch is taken in the
iteration if the attacker is able to run unprivileged code on the victim
machine (e.g., an app installed on a smart phone or potentially a
JavaScript code on a web site loaded by a web browser). This depends on
the used CPU not providing sufficient protection to prevent unprivileged
applications from observing memory access patterns through the shared
cache (which is the most likely case with today's designs).
The attacker could use information about the selected branch to learn
information about the password and combine this information from number
of handshake instances with an offline dictionary attack. With
sufficient number of handshakes and sufficiently weak password, this
might result in full recovery of the used password if that password is
not strong enough to protect against dictionary attacks.
This attack requires the attacker to be able to run a program on the
target device. This is not commonly the case on an authentication server
(EAP server), so the most likely target for this would be a client
device using EAP-pwd.
The commits listed in the end of this advisory change the EAP-pwd
implementation shared by hostapd and wpa_supplicant to perform the PWE
derivation loop using operations that use constant time and memory
access pattern to minimize the externally observable differences from
operations that depend on the password even for the case where the
attacker might be able to run unprivileged code on the same device.
Vulnerable versions/configurations
All wpa_supplicant and hostapd versions with EAP-pwd support
(CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled
in the runtime configuration).
It should also be noted that older versions of wpa_supplicant/hostapd
prior to v2.7 did not include additional protection against certain
timing differences. The definition of the EAP-pwd (RFC 5931) does not
describe such protection, but the same issue that was addressed in SAE
earlier can be applicable against EAP-pwd as well and as such, that
implementation specific extra protection (commit 22ac3dfebf7b, "EAP-pwd:
Mask timing of PWE derivation") is needed to avoid showing externally
visible timing differences that could leak information about the
password. Any uses of older wpa_supplicant/hostapd versions with EAP-pwd
are recommended to update to v2.7 or newer in addition to the mitigation
steps listed below for the more recently discovered issue.
Possible mitigation steps
- Merge the following commits to wpa_supplicant/hostapd and rebuild:
OpenSSL: Use constant time operations for private bignums
Add helper functions for constant time operations
OpenSSL: Use constant time selection for crypto_bignum_legendre()
EAP-pwd: Use constant time and memory access for finding the PWE
These patches are available from https://w1.fi/security/2019-2/
- Update to wpa_supplicant/hostapd v2.8 or newer, once available
- Use strong passwords to prevent dictionary attacks
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
SAE side-channel attacks
Published: April 10, 2019
Identifiers:
- VU#871675
- CVE-2019-9494 (cache attack against SAE)
Latest version available from: https://w1.fi/security/2019-1/
Vulnerability
Number of potential side channel attacks were discovered in the SAE
implementations used by both hostapd (AP) and wpa_supplicant
(infrastructure BSS station/mesh station). SAE (Simultaneous
Authentication of Equals) is also known as WPA3-Personal. The discovered
side channel attacks may be able to leak information about the used
password based on observable timing differences and cache access
patterns. This might result in full password recovery when combined with
an offline dictionary attack and if the password is not strong enough to
protect against dictionary attacks.
Cache attack
A novel cache-based attack against SAE handshake was discovered. This
attack targets SAE with ECC groups. ECC group 19 being the mandatory
group to support and the most likely used group for SAE today, so this
attack applies to the most common SAE use case. Even though the PWE
derivation iteration in SAE has protections against timing attacks, this
new cache-based attack enables an attacker to determine which code
branch is taken in the iteration if the attacker is able to run
unprivileged code on the victim machine (e.g., an app installed on a
smart phone or potentially a JavaScript code on a web site loaded by a
web browser). This depends on the used CPU not providing sufficient
protection to prevent unprivileged applications from observing memory
access patterns through the shared cache (which is the most likely case
with today's designs).
The attacker can use information about the selected branch to learn
information about the password and combine this information from number
of handshake instances with an offline dictionary attack. With
sufficient number of handshakes and sufficiently weak password, this
might result in full discovery of the used password.
This attack requires the attacker to be able to run a program on the
target device. This is not commonly the case on access points, so the
most likely target for this would be a client device using SAE in an
infrastructure BSS or mesh BSS.
The commits listed in the end of this advisory change the SAE
implementation shared by hostapd and wpa_supplicant to perform the PWE
derivation loop using operations that use constant time and memory
access pattern to minimize the externally observable differences from
operations that depend on the password even for the case where the
attacker might be able to run unprivileged code on the same device.
Timing attack
The timing attack applies to the MODP groups 22, 23, and 24 where the
PWE generation algorithm defined for SAE can have sufficient timing
differences for an attacker to be able to determine how many rounds were
needed to find the PWE based on the used password and MAC
addresses. When the attack is repeated with multiple times, the attacker
may be able to gather enough information about the password to be able
to recover it fully using an offline dictionary attack if the password
is not strong enough to protect against dictionary attacks. This attack
could be performed by an attacker in radio range of an access point or a
station enabling the specific MODP groups.
This timing attack requires the applicable MODP groups to be enabled
explicitly in hostapd/wpa_supplicant configuration (sae_groups
parameter). All versions of hostapd/wpa_supplicant have disabled these
groups by default.
While this security advisory lists couple of commits introducing
additional protection for MODP groups in SAE, it should be noted that
the groups 22, 23, and 24 are not considered strong enough to meet the
current expectation for a secure system. As such, their use is
discouraged even if the additional protection mechanisms in the
implementation are included.
Vulnerable versions/configurations
All wpa_supplicant and hostapd versions with SAE support (CONFIG_SAE=y
in the build configuration and SAE being enabled in the runtime
configuration).
Acknowledgments
Thanks to Mathy Vanhoef (New York University Abu Dhabi) and Eyal Ronen
(Tel Aviv University) for discovering the issues and for discussions on
how to address them.
Possible mitigation steps
- Merge the following commits to wpa_supplicant/hostapd and rebuild:
OpenSSL: Use constant time operations for private bignums
Add helper functions for constant time operations
OpenSSL: Use constant time selection for crypto_bignum_legendre()
SAE: Minimize timing differences in PWE derivation
SAE: Avoid branches in is_quadratic_residue_blind()
SAE: Mask timing of MODP groups 22, 23, 24
SAE: Use const_time selection for PWE in FFC
SAE: Use constant time operations in sae_test_pwd_seed_ffc()
These patches are available from https://w1.fi/security/2019-1/
- Update to wpa_supplicant/hostapd v2.8 or newer, once available
- In addition to either of the above alternatives, disable MODP groups
1, 2, 5, 22, 23, and 24 by removing them from hostapd/wpa_supplicant
sae_groups runtime configuration parameter, if they were explicitly
enabled since those groups are not considered strong enough to meet
current security expectations. The groups 22, 23, and 24 are related
to the discovered side channel (timing) attack. The other groups in
the list are consider too weak to provide sufficient security. Note
that all these groups have been disabled by default in all
hostapd/wpa_supplicant versions and these would be used only if
explicitly enabled in the configuration.
- Use strong passwords to prevent dictionary attacks
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
[bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Cherry-pick Multi-AP commits from uptream:
9c06f0f6a hostapd: Add Multi-AP protocol support
5abc7823b wpa_supplicant: Add Multi-AP backhaul STA support
a1debd338 tests: Refactor test_multi_ap
bfcdac1c8 Multi-AP: Don't reject backhaul STA on fronthaul BSS
cb3c156e7 tests: Update multi_ap_fronthaul_on_ap to match implementation
56a2d788f WPS: Add multi_ap_subelem to wps_build_wfa_ext()
83ebf5586 wpa_supplicant: Support Multi-AP backhaul STA onboarding with WPS
66819b07b hostapd: Support Multi-AP backhaul STA onboarding with WPS
8682f384c hostapd: Add README-MULTI-AP
b1daf498a tests: Multi-AP WPS provisioning
Add support for Multi-AP to the UCI configuration. Every wifi-iface gets
an option 'multi_ap'. For APs, its value can be 0 (multi-AP support
disabled), 1 (backhaul AP), 2 (fronthaul AP), or 3 (fronthaul + backhaul
AP). For STAs, it can be 0 (not a backhaul STA) or 1 (backhaul STA, can
only associate with backhaul AP).
Also add new optional parameter to wps_start ubus call of
wpa_supplicant to indicate that a Multi-AP backhaul link is required.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This updates hostapd to version the git version from 2018-12-02 which
matches the 2.7 release.
The removed patches were are already available in the upstream code, one
additional backport is needed to fix a compile problem.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The eapol-test application also uses the code with the newly activated
ubus support, add the missing dependency.
Fixes: f5753aae23 ("hostapd: add support for WPS pushbutton station")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
similar to hostapd, also add a ubus interface for wpa_supplicant
which will allow handling WPS push-button just as it works for hostapd.
In order to have wpa_supplicant running without any network
configuration (so you can use it to retrieve credentials via WPS),
configure wifi-iface in /etc/config/wireless:
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'wwan'
option mode 'sta'
option encryption 'wps'
This section will automatically be edited if credentials have
successfully been acquired via WPS.
Size difference (mips_24kc): roughly +4kb for the 'full' variants of
wpa_supplicant and wpad which do support WPS.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SSIDs may contain UTF8 characters but ideally hostapd should be told
this is the case so it can advertise the fact. Default enable this
option.
add uci option utf8_ssid '0'/'1' for disable/enable e.g.
config wifi-iface
option utf8_ssid '0'
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Add a basic variant which provides WPA-PSK only, 802.11r and 802.11w and
is intended to support 11r & 11w (subject to driver support) out of the
box.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Backport two upstream fixes to address overly verbose logging of MAC ACL
rejection messages.
Fixes: FS#1468
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This adds support for the WPA3-Enterprise mode authentication.
The settings for the WPA3-Enterpriese mode are defined in
WPA3_Specification_v1.0.pdf. This mode also requires ieee80211w and
guarantees at least 192 bit of security.
This does not increase the ipkg size by a significant size.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
OWE is defined in RFC 8110 and provides encryption and forward security
for open networks.
This is based on the requirements in the Wifi alliance document
Opportunistic_Wireless_Encryption_Specification_v1.0_0.pdf
The wifi alliance requires ieee80211w for the OWE mode.
This also makes it possible to configure the OWE transission mode which
allows it operate an open and an OWE BSSID in parallel and the client
should only show one network.
This increases the ipkg size by 5.800 Bytes.
Old: 402.541 Bytes
New: 408.341 Bytes
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This build the full openssl and wolfssl versions with SAE support which
is the main part of WPA3 PSK.
This needs elliptic curve cryptography which is only provided by these
two external cryptographic libraries and not by the internal
implementation.
The WPA3_Specification_v1.0.pdf file says that in SAE only mode
Protected Management Frames (PMF) is required, in mixed mode with
WPA2-PSK PMF should be required for clients using SAE, and optional for
clients using WPA2-PSK. The defaults are set now accordingly.
This increases the ipkg size by 8.515 Bytes.
Old: 394.026 Bytes
New: 402.541 Bytes
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add each variant to the matching PROVIDERS variables after evaluating
the respective hostapd*, wpad* and wpa* variant.
Each package providing the same feature will automatically conflict with
all prior packages providing the same feature.
This way we can handle the conflicts automatically without introducing
recursive dependencies.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Move common variables and/or values to the package (variant) default.
Add additional values in variant packages if necessary. Remove further
duplicates by introducing new templates.
Remove the ANY_[HOSTAPD|SUPPLICANT_PROVIDERS]_PROVIDERS. The are the
same as the variables without the any prefix. No need to maintain both
variables.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Clean up conflicts/provides/depends hell and add PROVIDES for
eapol-test variants while at it.
Update mesh-DFS patchset from Peter Oh to v5 (with local fixes) which
allows to drop two revert-patches for upstream commits which previously
were necessary to un-break mesh-DFS support.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Instead of selecting the SSL provider at compile time, build package
variants for each option so users can select the binary package without
having to build it themselves.
Most likely not all variants have actually ever been user by anyone.
We should reduce the selection to the reasonable and most used
combinations at some point in future. For now, build them all.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Support for building wpa_supplicant/hostapd against wolfssl has been
added upstream recently, add build option to allow users using it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The max_oper_chwidth settings was parsed incorrectly for big endian system.
This prevented the system to switch to VHT80 (or VHT160). Instead they were
mapped to:
* HT20: 20MHz
* VHT20: 20MHz
* HT40: 40MHz
* VHT40: 40MHz
* VHT80: 40MHz
* VHT160: 40MHz
This happened because each max_oper_chwidth setting in the config file was
parsed as "0" instead of the actual value.
Fixes: a4322eba2b ("hostapd: fix encrypted mesh channel settings")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Fix encrypted (or DFS) AP+MESH interface combination in a way similar
to how it's done for AP+STA and fix netifd shell script.
Refresh patches while at it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import two patches from Peter Oh to allow setting channel
bandwidth in the way it already works for managed interfaces.
This fixes mesh interfaces on 802.11ac devices always coming up in
VHT80 mode.
Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which
also skips secondary channel scan just like noscan works in AP mode.
This time also make sure to add all files to the patch before
committing it...
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import two patches from Peter Oh to allow setting channel
bandwidth in the way it already works for managed interfaces.
This fixes mesh interfaces on 802.11ac devices always coming up in
VHT80 mode.
Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which
also skips secondary channel scan just like noscan works in AP mode.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
For unencrypted mesh networks our scripts take care of setting
the various mesh_param values. wpa_supplicant changes somes of them
when being used for SAE encrypted mesh and previously didn't allow
configuring any of them. Add support for setting mesh_fwding (which
has to be set to 0 when using other routing protocols on top of
802.11s) and update our script to pass the value to wpa_supplicant.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
And import patchset to allow 802.11s mesh on DFS channels, see also
http://lists.infradead.org/pipermail/hostap/2018-April/038418.html
Fix sae_password for encryption mesh (sent upstream as well).
Also refreshed existing patches and fixed 463-add-mcast_rate-to-11s.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The following patches were merged upstream:
000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch
replaced by commit 0e3bd7ac6
001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch
replaced by commit cb5132bb3
002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch
replaced by commit 87e2db16b
003-Prevent-installation-of-an-all-zero-TK.patch
replaced by commit 53bb18cc8
004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch
replaced by commit 0adc9b28b
005-TDLS-Reject-TPK-TK-reconfiguration.patch
replaced by commit ff89af96e
006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch
replaced by commit adae51f8b
007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch
replaced by commit 2a9c5217b
008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch
replaced by commit a00e946c1
009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch
replaced by commit b488a1294
010-Optional-AP-side-workaround-for-key-reinstallation-a.patch
replaced by commit 6f234c1e2
011-Additional-consistentcy-checks-for-PTK-component-len.patch
replaced by commit a6ea66530
012-Clear-BSSID-information-in-supplicant-state-machine-.patch
replaced by commit c0fe5f125
013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch
replaced by commit 114f2830d
Some patches had to be modified to work with changed upstream source:
380-disable_ctrl_iface_mib.patch (adding more ifdef'ery)
plus some minor knits needed for other patches to apply which are not
worth being explicitely listed here.
For SAE key management in mesh mode, use the newly introduce
sae_password parameter instead of the psk parameter to also support
SAE keys which would fail the checks applied on the psk field (ie.
length and such). This fixes compatibility issues for users migrating
from authsae.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
