Commit d4913c585e ('OpenSSL: Fix EAP-FAST
peer regression') introduced a workaround to use a new SSL_CTX instance
set for TLSv1_method() when using EAP-FAST. While that works, it is
unnecessarily complex since there is not really a need to use a separate
SSL_CTX to be able to do that. Instead, simply use SSL_set_ssl_method()
to update the ssl_method for the SSL instance. In practice, this commit
reverts most of the tls_openssl.c changes from that earlier commit and
adds that single call into tls_connection_set_params() based on EAP-FAST
flag.
Signed-off-by: Jouni Malinen <j@w1.fi>
This provides a regression test that would have caught the recent
issue with tls_openssl.c change breaking EAP-FAST.
Signed-off-by: Jouni Malinen <j@w1.fi>
This can be used to determine whether the last TLS-based EAP
authentication instance re-used a previous session (e.g., TLS session
resumption or EAP-FAST session ticket).
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit introduces a QCA vendor command that allows interrogation of
the vendor-specific features supported by the device/driver. Currently
the only defined feature is the ability to offload key management.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 35efa2479f ('OpenSSL: Allow TLS
v1.1 and v1.2 to be negotiated by default') changed from using
TLSv1_method() to SSLv23_method() to allow negotiation of TLS v1.0,
v1.1, and v1.2.
Unfortunately, it looks like EAP-FAST does not work with this due to
OpenSSL not allowing ClientHello extensions to be configured with
SSL_set_session_ticket_ext() when SSLv23_method() is used. Work around
this regression by initiating a separate SSL_CTX instance for EAP-FAST
phase 1 needs with TLSv1_method() while leaving all other EAP cases
using TLS to work with the new default that allows v1.1 and v1.2 to be
negotiated. This is not ideal and will hopefully get fixed in the future
with a new OpenSSL method, but until that time, this can be used allow
other methods use newer TLS versions while still allowing EAP-FAST to be
used even if it remains to be constraint to TLS v1.0 only.
Signed-off-by: Jouni Malinen <j@w1.fi>
OpenSSL 0.9.8za added a fix for CVE-2014-0224 and the original fix broke
EAP-FAST support due to forgotten SSL3_FLAGS_CCS_OK marking for
tls_session_secret_cb. Fix for this regression was added into OpenSSL
1.x and newer. The same fix is needed in this backport patch for
0.9.8za.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit f5fa824e9a ('Update OpenSSL 0.9.8
patch for EAP-FAST support') changed the OpenSSL 0.9.8 patch to support
the new API that was introduced in OpenSSL 1.0.0 for EAP-FAST. As such,
there should be no valid users of the old API anymore and tls_openssl.c
can be cleaned up to use only the new API.
Signed-off-by: Jouni Malinen <j@w1.fi>
Some cases like ifconfig down/up may require MACsec restart. To make
sure the appropriate protect frames and replay parameters get configured
in cases where the interface was down, set these parameters from KaY
configuration to the driver before creating a new transmit SC. This
allows MACsec functionality to recover automatically on such restart.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This verifies that the corner case of a duplicated, retransmitted
Invitation Response frame ends up being dropped instead of being
processed twice for the case of Invitation Request getting resend with
social channel as an operating channel in case of no common channels
found.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Commit ac330cfd87 ('P2P: Reinvite with
social operation channel if no common channels') introduced a mechamisn
to reinvite a peer during a persistent group reinvocation from a GO with
a different operating channel proposal. This mechanism can fail if the
inviting device (GO) ends up getting a retransmitted, duplicated
Invitation Response frame processed second time while waiting for the
response to the retried Invitation Request (using one of the social
channels as the operating channel). IEEE 802.11 duplicate frame
detection mechanisms are supposed to prevent this type of sequence, but
not all drivers support those rules properly for pre-association frames,
including P2P Public Action frames.
Work around this issue by checking that the dialog token in the
Invitation Response frame matches the one from the last Invitation
Request if the special invitation retry mechanism is used. This is safer
to do now than to enable dialog token matching for all invitation cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds P2P_SERV_DISC_REQ, P2P_SERVICE_ADD, and P2P_SERVICE_DEL error
cases and P2P_SERVICE_FLUSH and P2P_SERC_DISC_EXTERNAL testing.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to get into more consistent state after the FLUSH
command. DISCONNECT followed by FLUSH could result in
wpa_s->disconnected being left to 1 and this resulted in a test failure,
e.g., when running wpas_ctrl_dup_network followed by
wpas_ctrl_enable_disable_network where the latter was expecting
ENABLE_NETWORK on a disabled network to connect automatically and that
does not happen if wpa_s->disconnected == 1.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for unmasking of 11b rates to fail if a P2P group is
terminated while the netdev is down (e.g., due to rfkill block). This
could result in the 11b TX rates being left masked for non-P2P
operations. This would be particularly unfortunate for channel 14 use
since OFDM rates are not allowed on channel 14 and only OFDM rates were
configured P2P. This issue showed up, e.g., when running hwsim test case
rfkill_autogo followed by ap_wps_conf_chan14.
It may be possible to allow the failed operation in cfg80211/mac80211,
but it looks better to work around this on wpa_supplicant side as well.
Try to unmask the 11b rates again on the next connection request if the
rate unmasking operation had failed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes it easier to debug issues related to TX rate masking for P2P
use cases (and unmasking for non-P2P).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
While these are using practically large enoungh buffer sizes, it is
better to be more consistent with checking os_snprintf() return value.
Signed-off-by: Jouni Malinen <j@w1.fi>
This converts os_snprintf() result validation cases to use
os_snprintf_error() for cases that were note covered by spatch and
semantic patches.
Signed-off-by: Jouni Malinen <j@w1.fi>
This converts os_snprintf() result validation cases to use
os_snprintf_error() in cases where success condition was used to execute
a step. These changes were done automatically with spatch using the
following semantic patch:
@@
expression E1,E2,E3;
statement S1;
@@
E1 = os_snprintf(E2, E3, ...);
- if (\( E1 >= 0 \| E1 > 0 \) && \( (size_t) E1 < E3 \| E1 < (int) E3 \| E1 < E3 \))
+ if (!os_snprintf_error(E3, E1))
S1
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds verification of os_snprintf() result against the maximum
buffer length. These changes were done automatically with spatch
using the following semantic patch:
@@
expression E1,E2,E3;
statement S1;
@@
E1 = os_snprintf(E2, E3, ...);
- if (\( E1 < 0 \| E1 <= 0 \))
+ if (os_snprintf_error(E3, E1))
(
S1
|
{ ... }
)
Signed-off-by: Jouni Malinen <j@w1.fi>
A single channel scan just before WPS_REG, WPS_PBC, and WPS_PIN commands
can be used to avoid having to run a full scan. This saves significant
amount of time in the WPS test cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, the immediate EAPOL authenticator startup was scheduled
without having received EAPOL-Start only for the case where WPA/WPA2 was
enabled. This can be extended to speed up non-WPA/WPA2 cases as well if
the STA includes WPS IE in Association Request frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
This increases wpa_supplicant_ie_txt(), print_bss_info(), and
wpa_supplicant_ctrl_iface_scan_result() testing coverage to include the
previously missing key management options.
Signed-off-by: Jouni Malinen <j@w1.fi>
Shift right on unsigned char limits the value to 0..63 which is within
bounds for base64_table[]. Anyway, some static analyzers do not seem to
understand that. See if an otherwise unnecessary masking gets rid of
false warnings. (CID 62858)
Signed-off-by: Jouni Malinen <j@w1.fi>
