Use imsi_privacy_cert as the name of the configuration parameter for the
X.509v3 certificate that contains the RSA public key needed for IMSI
privacy. The only allowed format for this information is a PEM-encoded
X.509 certificate, so the previous name was somewhat confusing.
Jouni Malinen [Mon, 23 May 2022 20:46:37 +0000 (23:46 +0300)]
Do not try to use network profile with invalid imsi_privacy_key
Disable a network profile that has set the imsi_privacy_key if a valid
key cannot be read from the specified file. Previously, this check was
done only after having associated, but there is no point in associating
just to see EAP authentication fail in such a case. This is needed for
avoiding connection attempts if the X.509 certificate for IMSI privacy
has expired.
Jouni Malinen [Sun, 22 May 2022 14:01:35 +0000 (17:01 +0300)]
OpenSSL: Drop security level to 0 with OpenSSL 3.0 when using TLS 1.0/1.1
Commit 9afb68b03976 ("OpenSSL: Allow systemwide secpolicy overrides for
TLS version") with commit 58bbcfa31b18 ("OpenSSL: Update security level
drop for TLS 1.0/1.1 with OpenSSL 3.0") allow this workaround to be
enabled with an explicit network configuration parameter. However, the
default settings are still allowing TLS 1.0 and 1.1 to be negotiated
just to see them fail immediately when using OpenSSL 3.0. This is not
exactly helpful especially when the OpenSSL error message for this
particular case is "internal error" which does not really say anything
about the reason for the error.
It is is a bit inconvenient to update the security policy for this
particular issue based on the negotiated TLS version since that happens
in the middle of processing for the first message from the server.
However, this can be done by using the debug callback for printing out
the received TLS messages during processing.
Drop the OpenSSL security level to 0 if that is the only option to
continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed
in wpa_supplicant default configuration and OpenSSL 3.0 with the
constraint on MD5-SHA1 use.
Johannes Berg [Sun, 22 May 2022 08:46:09 +0000 (11:46 +0300)]
tests: Work around reentrant logging issues due to __del__ misuse
Unfortunately, some objects (WlantestCapture, WpaSupplicant
and wpaspy.Ctrl) use __del__ and actually have some logic
there. This is more or less wrong, and we should be using
context managers for it. However, cleaning that up is a
pretty large task.
Unfortunately, __del__ can cause reentrant logging which is
wrong too, because it might be invoked while in the middle
of a logging call, and the __del__ of these objects closes
connections and logs while doing that.
Since we're (likely) using cpython, we can work around this
by explicitly calling gc.collect() in a context where the
logging and close is fine, not only ensuring that all the
connections are closed properly before the next test, but
also fixing the issue with reentrant logging.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jouni Malinen [Sun, 22 May 2022 08:43:38 +0000 (11:43 +0300)]
tests: Clean up failed test list in parallel-vm.py
Instead of printing a very long line of the failed tests, print the test
case names on separate lines up to the number of available lines at the
bottom of the screen. This avoids some issues with curses and overlong
lines. Furthermore, display the last failed test cases instead of
somewhat confusing sequence of test case names from the VMs.
Jouni Malinen [Mon, 16 May 2022 16:39:57 +0000 (19:39 +0300)]
EHT: Do not check HE PHY capability info reserved fields
Only use the bandwidth bits that are applicable for the current
operating band. This avoids use of reserved bits when determining the
length of the Support EHT-MCS And NSS Set field length.
Jouni Malinen [Mon, 16 May 2022 16:06:47 +0000 (19:06 +0300)]
tests: Update ap_wpa2_psk_ext_delayed_ptk_rekey to match implementation
This test case was checking the exact key info bits in EAPOL-Key frames
during PTK rekeying as such, needs to be updated to match the
implementation change on the Secure bit setting.
Jouni Malinen [Mon, 16 May 2022 14:34:12 +0000 (17:34 +0300)]
Use Secure=1 in PTK rekeying EAPOL-Key msg 1/4 and 2/4
IEEE Std 802.11-2020 is ambiguous on how the Secure bit is set in
EAPOL-Key msg 1/4 and 2/4 in the case where 4-way handshake is use to
rekey the PTK. 12.7.2 describes this with "set to 1 once the initial key
exchange is complete" while 12.7.6 shows EAPOL-Key msg 1/4 and 2/4 using
Secure=0 without any consideration on whether the handshake is for
rekeying.
TGme seems to be moving towards clarifying this to use Secure=1 based on
there being a shared PTKSA between the Authenticator and the Supplicant.
In other words, this would use Secure=1 in EAPOL-Key msg 1/4 and 2/4 in
the case of rekeying. Change implementation to match that. This bit was
already practically ignored on the reception side, so this should not
have impact on actual functionality beyond this one bit changing its
value in the frame.
Jouni Malinen [Mon, 9 May 2022 08:45:33 +0000 (11:45 +0300)]
tests: Wait for request before responding in dscp_response
There was a possible race condition here between the hostapd request
transmission and wpa_supplicant response command. Wait for the
wpa_supplicant event that indicates reception of the request before
issuing the DSCP_RESP command to avoid failures.
Jouni Malinen [Sun, 8 May 2022 14:18:58 +0000 (17:18 +0300)]
FST: More robust bounds checking of local data in fst_dump_mb_ies()
Check the full MBIE length against the buffer length explicitly before
the debug print. This is for locally generated data, so the bounds
checking is not critical here, but it is better to use proper checking
anyway to avoid static analyzer complaints.
Jouni Malinen [Sun, 8 May 2022 09:02:40 +0000 (12:02 +0300)]
GAS: Limit maximum comeback delay value
Limit the GAS comeback delay to 60000 TUs, i.e., about 60 seconds. This
is mostly to silence static analyzers that complain about unbounded
value from external sources even though this is clearly bounded by being
a 16-bit value.
Jouni Malinen [Sun, 8 May 2022 09:19:42 +0000 (12:19 +0300)]
WNM: Try to make bounds checking easier for static analyzers
The length of the URL, i.e., pos[0], is verified here to be within the
bounds of the recieved message, but that seemed to be done in a manner
that might bee too complex for static analyzers to understand.
Jouni Malinen [Sat, 7 May 2022 21:39:20 +0000 (00:39 +0300)]
Check he_cap pointer in hostapd_set_freq_params() consistently
The EHT changes made this checking inconsistent. If he_cap can be NULL
in case of EHT being enabled, better make sure it does not get
dereferenced without an explicit check.
Jouni Malinen [Sat, 7 May 2022 21:27:51 +0000 (00:27 +0300)]
FST: Make sure get_hw_modes() callback is set for hostapd
It looks like fst_wpa_obj::get_hw_modes would have been left
uninitialized in hostapd. It is not obviously clear why this would not
have caused issues earlier, but in any case, better make this set
properly to allow unexpected behavior should that function pointer ever
be used.
Jouni Malinen [Sat, 7 May 2022 20:58:03 +0000 (23:58 +0300)]
P2P: Explicit nul termination of the generated passphrase
Nul terminate the struct p2p_go_neg_results::passphrase explicitly to
keep static analyzers happier. This was already nul terminated in
practice due to the full array being cleared to zero on initialization,
but that was apparently not clear enough for some analyzers.
Ilan Peer [Sun, 24 Apr 2022 09:57:53 +0000 (12:57 +0300)]
scan: Add option to disable 6 GHz collocated scanning
Add a parameter (non_coloc_6ghz=1) to the manual scan command to disable
6 GHz collocated scanning.
This option can be used to disable 6 GHz collocated scan logic. Note
that due to limitations on Probe Request frame transmissions on the 6
GHz band mandated in IEEE Std 802.11ax-2021 it is very likely that
non-PSC channels would be scanned passively and this can take a
significant amount of time.
nl80211: Set NL80211_SCAN_FLAG_COLOCATED_6GHZ in scan
Set NL80211_SCAN_FLAG_COLOCATED_6GHZ in the scan parameters to enable
scanning for co-located APs discovered based on neighbor reports from
the 2.4/5 GHz bands when not scanning passively. Do so only when
collocated scanning is not disabled by higher layer logic.
Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com>
MeiChia Chiu [Fri, 6 May 2022 03:02:36 +0000 (11:02 +0800)]
hostapd: Add the destination address of unsolicited Probe Response frame
Without this, hostapd generates Probe Response frames with the null
destination address when hostapd enables unsolicited Probe Response
frame transmission. Fix this to use the broadcast address instead.
Jouni Malinen [Sat, 7 May 2022 15:10:17 +0000 (18:10 +0300)]
Discard unencrypted EAPOL/EAP when TK is set and PMF is enabled (AP)
RSN design is supposed to encrypt all Data frames, including EAPOL
frames, once the TK has been configured. However, there are deployed
implementations that do not really follow this design and there are
various examples from the older uses of EAPOL frame where those frames
were not encrypted. As such, strict filtering of unencrypted EAPOL
frames might results in undesired interoperation issues.
However, some of the most important cases of missing EAPOL frame
encryption should be possible to handle without causing too significant
issues. These are for cases where an attacker could potentially cause an
existing association to be dropped when PMF is used. EAPOL-Start and
EAPOL-Logoff are potential candidate for such attacks since those frames
could be used to terminate an authentication or initiate a new EAP
authentication. Such an attack could result in the station ending up
disconnecting or at minimum, getting into somewhat mismatching state
with the AP.
Drop EAPOL-Start/Logoff/EAP frames on the AP/Authenticator when it is
known that it was not encrypted but should have been and when PMF is
enabled. While it would be correct to drop this even without PMF, that
does not provide any significant benefit since it is trivial to force
disconnection in no-PMF cases. It should also be noted that not all
drivers provide information about the encryption status of the EAPOL
frames and this change has no impact with drivers that do not indicate
whether the frame was encrypted.
Jouni Malinen [Sat, 7 May 2022 14:42:51 +0000 (17:42 +0300)]
Discard unencrypted EAPOL-EAP when TK is set and PMF is enabled
RSN design is supposed to encrypt all Data frames, including EAPOL
frames, once the TK has been configured. However, there are deployed
implementations that do not really follow this design and there are
various examples from the older uses of EAPOL frame where those frames
were not encrypted. As such, strict filtering of unencrypted EAPOL
frames might results in undesired interoperation issues.
However, some of the most important cases of missing EAPOL frame
encryption should be possible to handle without causing too significant
issues. These are for cases where an attacker could potentially cause an
existing association to be dropped when PMF is used. EAP-Request is one
potential candidate for such attacks since that frame could be used to
initiate a new EAP authentication and the AP/Authenticator might not
allow that to complete or a large number of EAP-Request frames could be
injected to exceed the maximum number of EAP frames. Such an attack
could result in the station ending up disconnecting or at minimum,
getting into somewhat mismatching state with the AP.
Drop EAPOL-EAP frames when it is known that it was not encrypted but
should have been and when PMF is enabled. While it would be correct to
drop this even without PMF, that does not provide any significant
benefit since it is trivial to force disconnection in no-PMF cases. It
should also be noted that not all drivers provide information about the
encryption status of the EAPOL frames and this change has no impact with
drivers that do not indicate whether the frame was encrypted.
Jouni Malinen [Sat, 7 May 2022 08:54:16 +0000 (11:54 +0300)]
Discard unencrypted EAPOL-Key msg 1/4 when TK is set and PMF is enabled
RSN design is supposed to encrypt all Data frames, including EAPOL
frames, once the TK has been configured. However, there are deployed
implementations that do not really follow this design and there are
various examples from the older uses of EAPOL frame where those frames
were not encrypted. As such, strict filtering of unencrypted EAPOL
frames might results in undesired interoperation issues.
However, some of the most important cases of missing EAPOL frame
encryption should be possible to handle without causing too significant
issues. These are for cases where an attacker could potentially cause an
existing association to be dropped when PMF is used. EAPOL-Key msg 1/4
is one potential candidate for such attacks since that frame could be
used to initiate a 4-way handshake that the real AP might never complete
and the station might end up disconnecting because of that or at
minimum, getting into somewhat mismatching state with the AP.
Drop EAPOL-Key msg 1/4 when it is known that it was not encrypted but
should have been and when PMF is enabled. While it would be correct to
drop this even without PMF, that does not provide any significant
benefit since it is trivial to force disconnection in no-PMF cases. It
should also be noted that not all drivers provide information about the
encryption status of the EAPOL frames and this change has no impact with
drivers that do not indicate whether the frame was encrypted.
Jouni Malinen [Sat, 7 May 2022 08:14:50 +0000 (11:14 +0300)]
Do not prevent Michael MIC error report based on disallowed PTK0 rekey
EAPOL-Key Request frame with Error=1 is not really a request for a new
key, so allow that frame to be sent even if PTK0 rekey is not allowed
since the supplicant is required to report Michael MIC errors to the
authenticator.
Jouni Malinen [Fri, 6 May 2022 21:38:35 +0000 (00:38 +0300)]
Provide information about the encryption status of received EAPOL frames
This information was already available from the nl80211 control port RX
path, but it was not provided to upper layers within wpa_supplicant and
hostapd. It can be helpful, so parse the information from the driver
event.
Jouni Malinen [Sat, 7 May 2022 17:34:07 +0000 (20:34 +0300)]
FILS: Set pairwise_set when configuring TK after association
sm->pairwise_set needs to be set whenever the TK has been configured to
the driver to request following EAPOL frames to be encrypted (or more
specifically, not to request them to not be encrypted). The FILS case
missed this setting and that could result in rekeying or
reauthentication in an associated started with FILS not working
correctly.
Fixes: da24c5aa1c47 ("FILS: Set TK after association (AP)") Signed-off-by: Jouni Malinen <j@w1.fi>
Jouni Malinen [Fri, 6 May 2022 21:58:41 +0000 (00:58 +0300)]
Fix no_encrypt flag in control port TX for rekeying
The wpa_supplicant check for whether a TK is configured into the driver
was broken during the time this information is needed for rekeying or
reauthenticating with another 4-way handshake. sm->ptk.installed is not
set at the point the EAPOL-Key msg 4/4 is sent and while that means the
initial 4-way handshake needs to prevent encryption, the consecutive
4-way handshake must not be doing that since the old key (TK) is still
in the driver. Fix this so that the EAPOL-Key msg 4/4 during rekeying
does not get transmitted without encryption.
Fixes: a79ed0687197 ("Add no_encrypt flag for control port TX") Signed-off-by: Jouni Malinen <j@w1.fi>
Domien Schepers [Thu, 5 May 2022 19:53:26 +0000 (21:53 +0200)]
WPA: Discard EAPOL-Key msg 1/4 with corrupted information elements
Currently a corrupted handshake message 1/4 causes the client to
disconnect from the network. This can lead to a denial-of-service
vulnerability allowing an adversary to forcibly disconnect a client from
protected networks even when Wi-Fi Management Frame Protection (MFP) is
enforced if the driver allows unencrypted EAPOL-Key frames to be
received after key configuration..
Fix this by discarding the corrupted handshake message 1/4.
This issue was discovered by Domien Schepers (Northeastern University)
and Mathy Vanhoef (imec-DistriNet, KU Leuven).
Jouni Malinen [Sat, 7 May 2022 15:49:57 +0000 (18:49 +0300)]
Check need for SA Query/assoc comeback before updating RSNE parameters
wpa_validate_wpa_ie() might update sm->* values, so it should not be
allowed for an existing STA entry if that STA has negotiated MFP to be
used for the association. Fix this by first checking whether an SA Query
procedure needs to be initiated. In particular, this prevents a
potential bypass of the disconnection protection.
nl80211: Don't force VHT channel definition with EHT
Add a check to avoid sending VHT channel definition when EHT is enabled
in the 2.4 GHz band since the 2.4 GHz band isn't supposed to use VHT
operations. Also add EHT enabled info into debug prints.
EHT: Indicate wifi_generation=7 in wpa_supplicant STATUS output
This adds wifi_generation=7 line to the STATUS output if the driver
reports (Re)Association Request frame and (Re)Association Response frame
information elements in the association or connection event with EHT
capability IEs.
EHT: Fix invalid length checking for EHT Capability element
Do not consider optional octets maximum lengths when validating EHT
fixed fields length. Furthermore, do not use the first two octets of the
PPE Thresholds field without explicitly confirming that these octets
were included in the element and fix PPE Thresholds field length
calculation.
SAE: Send real status code to the driver when AP rejects external auth
Send the status code from the AP authentication response instead of
sending the hardcoded WLAN_STATUS_UNSPECIFIED_FAILURE when the external
SAE authentication failure is due to an explicit rejection by the AP.
This will allow the driver to indicate the correct status in connect
response.
For example, an AP can send WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA in
SAE authentication response. With this change the driver gets the real
status for the SAE authentication failure and it can fill the correct
status in the connect response event.
Sunil Ravi [Thu, 5 May 2022 06:25:43 +0000 (23:25 -0700)]
Fix compilation due to forward declaration of macaddr_acl
enum macaddr_acl is forward declared in wpa_supplicant/ap.h.
c++ compiler doesn't allow forward declaration. So to fix the
compilation error, moved the enum macaddr_acl declaration out
of struct hostapd_bss_config.
Jouni Malinen [Wed, 4 May 2022 21:35:47 +0000 (00:35 +0300)]
OpenSSL: Fix build with old library versions that do not support TLS 1.3
The OCSP check here is specific to TLS 1.3 and the TLS1_3_VERSION value
is not available in older library versions. Comment this check out from
such cases since it is not applicable with such an old library.
Fixes: 10746875e27a ("OpenSSL: Allow no OCSP response when resuming a session with TLS 1.3") Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Jouni Malinen [Wed, 4 May 2022 21:34:25 +0000 (00:34 +0300)]
LibreSSL: Fix compilation issue with TLS 1.3 session ticket limit
LibreSSL does not seem have SSL_CTX_set_num_tickets(), so comment out
these not really critical calls when building with that library.
Fixes: 81e24988895a ("OpenSSL: Limit the number of TLS 1.3 session tickets to one") Fixes: decac7cd1e50 ("OpenSSL: Do not send out a TLS 1.3 session ticket if caching disabled") Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Jouni Malinen [Wed, 4 May 2022 21:31:43 +0000 (00:31 +0300)]
LibreSSL: Fix compilation issue with RSA-OAEP
EVP_PKEY_CTX_set_rsa_oaep_md() does not seem to be available in
LibreSSL, so for now, comment out this functionality whenever building
with that library.
Sunil Ravi [Thu, 5 May 2022 06:46:35 +0000 (23:46 -0700)]
BoringSSL: Fix compilation error due to TLS 1.3 session tickets
SSL_CTX_set_num_tickets() is not available in boringSSL.
So protect the call to SSL_CTX_set_num_tickets() under
!defined(OPENSSL_IS_BORINGSSL) to fix the compilation error.
Fixes: decac7cd1e50 ("OpenSSL: Do not send out a TLS 1.3 session ticket if caching disabled") Fixes: 81e24988895a ("OpenSSL: Limit the number of TLS 1.3 session tickets to one") Signed-off-by: Sunil Ravi <sunilravi@google.com>
Jouni Malinen [Wed, 4 May 2022 21:07:44 +0000 (00:07 +0300)]
EAP peer: Workaround for servers that do not support safe TLS renegotiation
The TLS protocol design for renegotiation was identified to have a
significant security flaw in 2009 and an extension to secure this design
was published in 2010 (RFC 5746). However, some old RADIUS
authentication servers without support for this are still used commonly.
This is obviously not good from the security view point, but since there
are cases where the user of a network service has no realistic means for
getting the authentication server upgraded, TLS handshake may still need
to be allowed to be able to use the network.
OpenSSL 3.0 disabled the client side workaround by default and this
resulted in issues connection to some networks with insecure
authentication servers. With OpenSSL 3.0, the client is now enforcing
security by refusing to authenticate with such servers. The pre-3.0
behavior of ignoring this issue and leaving security to the server can
now be enabled with a new phase1 parameter allow_unsafe_renegotiation=1.
This should be used only when having to connect to a network that has an
insecure authentication server that cannot be upgraded.
The old (pre-2010) TLS renegotiation mechanism might open security
vulnerabilities if the authentication server were to allow TLS
renegotiation to be initiated. While this is unlikely to cause real
issues with EAP-TLS, there might be cases where use of PEAP or TTLS with
an authentication server that does not support RFC 5746 might result in
a security vulnerability.
Jouni Malinen [Tue, 3 May 2022 21:05:09 +0000 (00:05 +0300)]
Fix tls_connection_set_success_data() in TLS library wrappers
Some of the TLS library wrappers defined only an empty function for
tls_connection_set_success_data(). That could result in memory leaks in
TLS server cases, so update these to do the minimal thing and free the
provided buffer as unused.
Jouni Malinen [Mon, 2 May 2022 14:29:35 +0000 (17:29 +0300)]
EAP-PEAP server: Fix TLS 1.3 move to Phase 2 without a new session ticket
When a new session ticket is not issued to the peer, Phase 2 identity
request need to be sent out as a response to the Finished message from
the peer. Fix this to allow the TLS server to be configured to not send
out a new session ticket when using TLS 1.3.
Jouni Malinen [Mon, 2 May 2022 13:54:13 +0000 (16:54 +0300)]
OpenSSL: Allow no OCSP response when resuming a session with TLS 1.3
TLS 1.3 sends the OCSP response with the server Certificate message.
Since that Certificate message is not sent when resuming a session,
there can be no new OCSP response. Allow this since the OCSP response
was validated when checking the initial certificate exchange.
Jouni Malinen [Mon, 2 May 2022 13:23:20 +0000 (16:23 +0300)]
EAP-TLS peer: Fix protected success indication check for resumed session
The internal flag prot_success_received was not cleared between the
sessions and that resulted in the resumed session not mandating the
protected success indication to be received. Fix this by clearing the
internal flag so that the EAP-TLS handshake using session resumption
with TLS 1.3 takes care of the required check before marking the
authentication successfully completed. This will make the EAP-TLS peer
reject an EAP-Success message should it be received without the
protected success indication.
Jouni Malinen [Mon, 2 May 2022 13:19:06 +0000 (16:19 +0300)]
EAP-TLS server: Send final TLS message for resumed session with TLS 1.3
The final message with NewSessionTicket and ApplicationData(0x00) was
already generated, but that was not sent out due the session considered
to be already completed. Fix this by actually sending out that message
to allow the peer to receive the new session ticket and protected
success indication when using resuming a session with TLS 1.3.
pbkdf2_sha1() may return errors and this should be checked in calls.
This is especially an issue with FIPS builds because the FIPS
requirement is that the password must be at least 14 characters.
projects / thirdparty / hostap.git / log
