using psk instead of sae_password in wpa_supplicant.conf does not work - wpa-supplicant

trying to formulate a wpa_supplicant.conf that can be used to connect to a variety of different networks especially wpa2 and wpa3 Networks, I want to use the following property: "sae_password: SAE password
This parameter can be used to set a password for SAE. By default, the passphrase from the psk parameter is used if this separate parameter is not used" to not write the Password twice into the file - under psk and sae_password. But the connection to a wpa3 network only works if the sae_password is added.
tried a wpa_supplicant.conf with the following content:
"
country=us
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=root
update_config=1
network=
{ ssid="WiFi6_Asus-Mesh" #psk="xxxxxx" psk=41c968ef5fec62485ea123e992128b1123aba773953cc6c01074392679718f6a key_mgmt=SAE WPA-PSK WPA-PSK-SHA256 pairwise=CCMP group=CCMP proto=RSN ieee80211w=1 sae_password="xxxxxx" }"
and connection to a wpa3 AP worked fine. Discarding the the sae_password="xxxxxx" however did lead to:
entered:
wpa_supplicant -iwlan0 -Dnl80211 -cwpa_supplicant.conf
got:
Successfully initialized wpa_supplicant
wlan0: Trying to associate with fc:34:97:23:a2:68 (SSID='WiFi6_Asus-Mesh' freq=2437 MHz)
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=fc:34:97:23:a2:68 status_code=1
wlan0: Trying to associate with fc:34:97:23:a2:68 (SSID='WiFi6_Asus-Mesh' freq=2437 MHz)
wlan0: Authentication with fc:34:97:23:a2:68 timed out.
wlan0: CTRL-EVENT-DISCONNECTED bssid=fc:34:97:23:a2:68 reason=3 locally_generated=1
etc.
adding sae_pk=0 to the conf file did not help.
Because of the documentation cited above i did expect, that the psk would be taken when the sae_password is discarded. But in my case this did not work out. why? did i misunderstand the documentation?

misunderstanding of the documentation on my side: The functionality of "By default, the passphrase from the psk parameter is used if this (sae_password) separate parameter is not used" works indeed - if the psk is given correctly. In the above configuration I gave the hashed psk and only gave the cleartext like #psk="xxxxxx" which causes wpa_supplicant to not use the cleartext which apparently is required instead of the hashed one for wpa3 to work. In detail - here is the configuration that works:
country=us
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=root
update_config=1
network={
ssid="WiFi6_Asus-Mesh"
psk="xxxxxx"
key_mgmt=SAE WPA-PSK WPA-PSK-SHA256
pairwise=CCMP
group=CCMP
proto=RSN
ieee80211w=1
}

Related

Unable to decrypt TLS 1.3 packets with the keys got using SSL_CTX_set_keylog_callback openssl API in Wireshark

I'm working on a task where i need to decrypt all the TLS 1.3 encrypted packets in wireshark (using Edit->Preferences->Protocol->TLS->pre-Master_secret log filename option) for debugging purpose. so i stored all the keys of TLS 1.3 sessions by setting the call back function with openssl provided API() call back function into a file as shown below:
SSL_CTX_set_keylog_callback(pCtx_m,Keylog_cb_func);
void Keylog_cb_func(const SSL *ssl, const char *line) {
// Code to log the line into a file in append mode
}
With this, i'm able to decrypt the TLS 1.3 packets with the keys logged into the file for only the below three ciphers in wireshark
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
and the other two ciphers of TLS1.3 TLS_AES_128_CCM_8_SHA256 , TLS_AES_128_CCM_SHA256 is not getting decrypted using the keys (in wireshark) opensll API has given though the calls are established over these two ciphers successfully.
I have read this post in stackoverflow about the default enabled cipher suite but i'm not quite sure about if this issue is something related to that. Could anyone help me to understand what i'm doing wrong here:
Sample Key File:
SERVER_HANDSHAKE_TRAFFIC_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 aa48ffe195090f87138caf32a520ecd41644f23f6d778f6436b5e2d697452572
CLIENT_HANDSHAKE_TRAFFIC_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 415e363721b8e204d3e2a2f94682d25792f565770a0f9221e86738d1c540e21b
EXPORTER_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 25276ba5f066f69b6caac00d35e981ff0b7d70e20d541c9435538d32a640ecdc
SERVER_TRAFFIC_SECRET_0 dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 9d683bacbb0ce07fa5d0425c2763920f11d98af85c7461a52e26efb6bdaf74b5
CLIENT_TRAFFIC_SECRET_0 dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 bfca7bc330de3836b0e49619375b504f4d2794206c4ecc7fcd1dfdab363bd36a
SERVER_HANDSHAKE_TRAFFIC_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 1be3cc095c1e336168ab10619c266eaf7a9057edf724d65f3016ba64d642ab0f
EXPORTER_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 0cfa53e94a8a6cf085af19a45a062152299b5ccea84cbffe237f136f0854672e
SERVER_TRAFFIC_SECRET_0 cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 7de206865a34e1b3b004d47075d534ebfd60b47a16ce525f3c0da47c9c78c57f
CLIENT_HANDSHAKE_TRAFFIC_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 1a4cad91d84607f44cd6a65cf1e9bcddaf3488d2dcb67b5246995485226dfa5c
CLIENT_TRAFFIC_SECRET_0 cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 be0df5b77fb5edb1785118e6adb119a5820beacb74d01d8cdee344d3feb56488
Wireshark Version: Version 3.6.1 (v3.6.1-0-ga0a473c7c1ba).
Thanks in advance
Prakash
It's found that wireshark Version 3.6.7 (v3.6.7-0-g4a304d7ec222) itself currently has an issue in the TLS 1.3 packet decryption feature for these two ciphers (LS1.3 TLS_AES_128_CCM_8_SHA256 , TLS_AES_128_CCM_SHA256 ) due to invalid-aad-length, and the same would be fixed in the upcoming version. We have reported a bug to the wirshark forum as in the link below
https://gitlab.com/wireshark/wireshark/-/issues/18277

IBM MQ expects username and password when using SSL certificates (Error 2035)

I am stuck at using SSL in IBM Websphere MQ (9.2).
I am building a client library for MQ and to get more familiar with MQ on the server side I have installed IBM MQ Developer edition and ran the supplied scripts to create a 'default' MQ server instance.
Created an client connection for the DEV.APP.SVRCONN server connection
Created a personal certificate by using the IBM Key management tool and named it ibmwebspheremq
Enabled SSL on the Queue Manager (QM1) and labelled it ibmwebspheremq
Updated the SSL configuration for the DEV.APP.SVRCONN channel and set the cipherspec property to TLS 1.2, 256-bit Secure Hash Algorithm, 128-bit AES encryption (TLS_RSA_WITH_AES_128_CBC_SHA256) and made SSL required.
Tested my settings with:
amqssslc -l ibmwebspheremq -k C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key -c DEV.APP.SVRCONN -x 127.0.0.1 -s TLS_RSA_WITH_AES_128_CBC_SHA256 -m QM1
And that gave me:
Sample AMQSSSLC start
Connecting to queue manager QM1
Using the server connection channel DEV.APP.SVRCONN
on connection name 127.0.0.1.
Using SSL CipherSpec TLS_RSA_WITH_AES_128_CBC_SHA256
Using SSL key repository stem C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key
Certificate Label: ibmwebspheremq
No OCSP configuration specified.
MQCONNX ended with reason code 2035
Error details (from log):
The active values of the channel were 'MCAUSER(app) CLNTUSER(Wilko)
SSLPEER(SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL)
SSLCERTI(CN=DESKTOP-ROH98N2,C=NL) ADDRESS(DESKTOP-ROH98N2)'. The
MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH MQSC command can be used to
identify the relevant CHLAUTH record.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager connection authority (CONNAUTH) configuration to OPTIONAL to
allow client applications to connect which have not supplied a user ID and
password.
----- cmqxrmsa.c : 2086 -------------------------------------------------------
22/11/2021 15:51:37 - Process(15880.45) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(DESKTOP-ROH98N2) Installation(Installation1)
VRMF(9.2.3.0) QMgr(QM1)
Time(2021-11-22T14:51:37.594Z)
CommentInsert1(DEV.APP.SVRCONN)
CommentInsert2(15880(1112))
CommentInsert3(127.0.0.1)
AMQ9999E: Channel 'DEV.APP.SVRCONN' to host '127.0.0.1' ended abnormally.
EXPLANATION:
The channel program running under process ID 15880(1112) for channel
'DEV.APP.SVRCONN' ended abnormally. The host name is '127.0.0.1'; in some cases
the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 630 --------------------------------------------------------
I am kind of stuck, I also saw in the log that there is PEER related info dumped, but I am not sing the SSLPEER settings (I just want to let everyone connect with the same certificate).
EDIT 2:
Output from RUNMQSC QM1 and command DISPLAY QMGR CONNAUTH:
1 : DISPLAY QMGR CONNAUTH
AMQ8408I: Display Queue Manager details.
QMNAME(QM1) CONNAUTH(DEV.AUTHINFO)
Output from RUNMQSC QM1 and command DISPLAY AUTHINFO(name-from-previous-command):
3 : DISPLAY AUTHINFO(DEV.AUTHINFO)
AMQ8566I: Display authentication information details.
AUTHINFO(DEV.AUTHINFO) AUTHTYPE(IDPWOS)
ADOPTCTX(YES) DESCR( )
CHCKCLNT(REQDADM) CHCKLOCL(OPTIONAL)
FAILDLAY(1) AUTHENMD(OS)
ALTDATE(2021-11-18) ALTTIME(15.09.20)
Output from DISPLAY CHLAUTH(*):
4 : DISPLAY CHLAUTH(*)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(USERMAP)
CLNTUSER(admin) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(BLOCKUSER)
USERLIST(nobody)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.APP.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
CHCKCLNT(REQUIRED)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
I was expecting not having to provide username and password when using certificates. What am I missing here?
Your queue manager is configured to mandate passwords for any client connections that are trying to run with a resolved MCAUSER that is privileged. That is what CHCKCLNT(REQDADM) on your AUTHINFO(DEV.AUTHINFO) does.
In addition, your CHLAUTH rule for the DEV.APP.SVRCONN channel has upgraded this further to mandate passwords for ALL connections using that channel.
If your intent is to have channels that supply a certificate not be subject to this mandate, then you should add a further, more specific, CHLAUTH rule, something along these lines:-
SET CHLAUTH(DEV.APP.SVRCONN) TYPE(SSLPEERMAP) +
SSLPEER('SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL') +
SSLCERTI('CN=DESKTOP-ROH98N2,C=NL') CHCKCLNT(ASQMGR) USERSRC(CHANNEL)
Bear in mind that if this connection is asserting a privileged user id, it will still be required to supply a password from the system-wide setting of CHCKCLNT(REQDADM).
Remember, if you are ever unsure which CHLAUTH rule you are matching against, all those details you saw in the error message can be used to form a DISPLAY CHLAUTH command to discover exactly which rule you have matched. Read more about that in I’m being blocked by CHLAUTH – how can I work out why?

mbsync authentication failed

I was able to configure mbsync and mu4e in order to use my gmail account (so far everything works fine). I am now in the process of using mu4e-context to control multiple accounts.
I cannot retrieve emails from my openmailbox account whereas I receive this error
Reading configuration file .mbsyncrc
Channel ombx
Opening master ombx-remote...
Resolving imap.ombx.io... ok
Connecting to imap.ombx.io (*.*.10*.16*:*9*)...
Opening slave ombx-local...
Connection is now encrypted
Logging in...
IMAP command 'LOGIN <user> <pass>' returned an error: NO [AUTHENTICATIONFAILED] Authentication failed.
In other posts I've seen people suggesting AuthMechs Login or PLAIN but mbsync doesn't recognizes the command. Here is my .mbsyncrc file
IMAPAccount openmailbox
Host imap.ombx.io
User user#openmailbox.org
UseIMAPS yes
# AuthMechs LOGIN
RequireSSl yes
PassCmd "echo ${PASSWORD:-$(gpg2 --no-tty -qd ~/.authinfo.gpg | sed -n 's,^machine imap.ombx.io .*password \\([^ ]*\\).*,\\1,p')}"
IMAPStore ombx-remote
Account openmailbox
MaildirStore ombx-local
Path ~/Mail/user#openmailbox.org/
Inbox ~/Mail/user#openmailbox.org/Inbox/
Channel ombx
Master :ombx-remote:
Slave :ombx-local:
# Exclude everything under the internal [Gmail] folder, except the interesting folders
Patterns *
Create Slave
Expunge Both
Sync All
SyncState *
I am using Linux Mint and my isync is version 1.1.2
Thanks in advance for any help
EDIT: I have run a debug option and I have upgraded isync to version 1.2.1
This is what the debug returned:
Reading configuration file .mbsyncrc
Channel ombx
Opening master store ombx-remote...
Resolving imap.ombx.io... ok
Connecting to imap.ombx.io (*.*.10*.16*:*9*)...
Opening slave store ombx-local...
pattern '*' (effective '*'): Path, no INBOX
got mailbox list from slave:
Connection is now encrypted
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Openmailbox is ready to
handle your requests.
Logging in...
Authenticating with SASL mechanism PLAIN...
>>> 1 AUTHENTICATE PLAIN <authdata>
1 NO [AUTHENTICATIONFAILED] Authentication failed.
IMAP command 'AUTHENTICATE PLAIN <authdata>' returned an error: NO [AUTHENTICATIONFAILED] Authentication failed.
My .msyncrc file now contains these options instead
SSLType IMAPS
SSLVersions TLSv1.2
AuthMechs PLAIN
At the end, the solution was to use the correct password. Since openmailbox uses an application password for third-party e-mail clients I was using the wrong (original) password instead of the application password.

FusionPBX Inbound Route ACL Error Can't Find User

i've changed my sip providers ip to MY.SIP.PROV.IP and their domain to MYSIPPROVIDER.COM and also my phone number to XXXXXXXXXX....
This is the CLI log. I'm able to dial out but I cannot get inbound routes working... Any help is appreciated.
Main part I'm not understanding:
2016-03-09 22:59:50.981898 [DEBUG] sofia.c:9124 IP MY.SIP.PROV.IP Rejected by acl "domains". Falling back to Digest auth.
Second Part....
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:2852 Can't find user [#MYSIPPROVIDER.COM] from MY.SIP.PROV.IP
You must define a domain called 'MYSIPPROVIDER.COM' in your directory and add a user with the id="" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:1703 SIP auth failure (INVITE) on sofia profile 'internal' for [XXXXXXXXXX#MYSIPPROVIDER.COM] from ip MY.SIP.PROV.IP
If you look at the vars.xml file (located in /etc/freeswitch/vars.xml if you installed from the FreeSWITCH package) you'll see two relevant settings..
<X-PRE-PROCESS cmd="set" data="internal_sip_port=5060"/>
<X-PRE-PROCESS cmd="set" data="external_sip_port=5080"/>
In short, if a SIP packet is sent to your FreeSWITCH box on port 5080, it get's routed to the /etc/freeswitch/dialplan/public.xml file. Which, if you installed from package, also includes any .xml in /etc/freeswitch/dialplan/public/ using the line..
<X-PRE-PROCESS cmd="include" data="public/*.xml"/>
Otherwise, if you receive a packet on port 5060 of your FreeSWITCH box it gets treated as an 'internal' call. These get treated a little differently. If you're using default/example configuration, one of the differences is the FreeSWITCH ACL or 'Access Control List'.
Basically, any call made to 5060 will be parsed by the ACL. Which you can perceive as a sort of firewall. If it doesn't match a rule in there, FreeSWITCH refuses it with the error.
2016-03-09 22:59:50.981898 [DEBUG] sofia.c:9124 IP MY.SIP.PROV.IP Rejected by acl "domains". Falling back to Digest auth.
And this part...
2016-03-09 22:59:50.981898 [WARNING] sofia_reg.c:2852 Can't find user [#MYSIPPROVIDER.COM] from MY.SIP.PROV.IP
You must define a domain called 'MYSIPPROVIDER.COM' in your directory and add a user with the id="" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
...is being generated by this part of the ACL config...
<list name="domains" default="deny">
<node type="allow" domain="$${domain}"/>
</list>
...Take not of the "Allow any SIP packet where the 'domain' (eg the #mysipprovider.com part of the SIP URI) is part of a user defined in the 'FreeSWITCH Directory'.
In short, the ACL is used as an added measure of authenticating INTERNAL DEVICES, in the context where FreeSWITCH is used as an 'internal PBX'.
You have two options..
Ask mysipprovider to route inbound SIP packets to port 5080, and then look at managing inbound calls via the default /etc/freeswitch/dialplan/public/00_inbound_did.xml file
Add a specific line in the ACL to approve calls from mysipprovider. Maybe something like..
..then type..
fs_cli -x 'reloadacl'
..to apply it.

How to enable certain cipher-suites in WildFly?

I want to explicitly enable certain cipher-suites on my WildFly application server.
Therefore I tried to edit the configuration in wildflys standalone.xml.
Let's assume I want to enable the AES128-GCM-SHA256 cipher (cipher suite names from: OpenSSL documentation).
I've edited the standalone.xml file of my WildFly server like this:
<https-listener name="listener" socket-binding="https" security-realm="ssl-realm" enabled-cipher-suites="AES128-GCM-SHA256"/>
The WildFly boots up normally but when I open the page in my browser an error message appears.
Chrome says:
ERR_SSL_PROTOCOL_ERROR
Firefox says:
ssl_error_internal_error_alert
I've tried this with WildFly 8.1 and 8.2.
Anybody out there who can give my an advice how to correctly enable certain cipher-suites?
Regards Tom
You have to add a attribute called "enabled-cipher-suites" to the "https-listener" found at "subsystem undertow" -> "server".
An example for this configuration can be found here.
Unfortunately this example is wrong when it comes to the value of this attribute. You must not name such things as "ALL:!MD5:!DHA" but instead some explicit cipher suites.
You have to call em by their SSL or TLS cipher suites names and not their OpenSSL names.
So instead of "AES128-GCM-SHA256" you have to write "TLS_RSA_WITH_AES_128_GCM_SHA256".
To make the confusion complete you have to use "," instead of ":" as delimiter if you want to name more than one suite.
Regards
Ben
I can confirm Ben's answer. The documentation for how to configure this is sparse. I would suggest the following ciphers to support:
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
in addition, the 'ALL' tag does not work and the best method is to list the ones that you wish to include and not the ones that you wish to exclude as that '!' marking does not appear to be supported.