I'm building an IRC client and am currently attempting to add SASL support. I have got it working just fine (authentication works), however, there's an annoying "glitch":
As I've understood, the SASL request must be done BEFORE registration, like so:
if (sasl) {
send("CAP REQ :sasl");
}
send("NICK: " + nick);
send("USER ....");
Now the annoying little thing is that the SASL request causes the IRC server to send back an ERR_NOTREGISTERED (451) reply. Now I could of course just ignore the very first 451 reply if SASL is enabled, but that seems a bit nasty. Am I missing something here?
Well, SASL on IRC is based on the Client CAPability Negotiation.
According to this specification you send a CAP LS at the beginning, after this you send the USER and NICK. If you recive a CAP response before the end of the motd/motd missing, the server supports CAP. Check if SASL is on the list of supported extensions, and request it.
If you get the end of motd/motd missing first, the server does not support CAP, and therefore does not support SASL.
Related
CocoaMQTT client is running on iOS15 with the SSL enabled as shown in this example. The cert_key.p12 file was merged from the client.crt and client.key files signed by the same (self-created) CA that was used for the MQTT server/broker certificate generation. The MQTT broker is configured to require client's certificate and use its CN as the username. The handshake does not go well - the log complains about the unknown certificate:
New connection from 192.168.1.87 on port 8883.
OpenSSL Error[0]: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
Based on the above error research, the broker does not like the client's certificate, right? In fact, looking at the wireshark's log, it seems like the client does not send the certificate to the server. Is that something I need to enable in the App configuration? Does the Swift CocoaMQTT package even support this feature (provide the cert to the broker)?
EDIT:
I tried running a client with the same cert/key with paho mqtt implemented in python, which also allows to provide the client with the CA certificate, and everything runs ok:
Trying using the same client's cert/key in CocoaMQTT implemented in iOS15 shows the MQTT broker log error message as above and the fatal alert shows up the the wireshark log:
Initially, I thought that the sever did not like (or did not receive) the client's certificate, but that fatal alert package destination is port 8883. So now I tend to believe that it's the client, who does not like the server's certificate. This is expected if the client uses the pool of official CAs to verify the certificate instead of recognizing that its own certificate was issued by the same CA as the server's one. This is further confirmed by setting the allowUntrustCACertificate = true and seems like the handshake is suspended and no more communication occurs:
There's also a debug message on the client's side:
Call the SSL/TLS manually validating function
So it looks like the client will not continue the communication until this validation process occurs. As #Brits mentioned in his comment, there's a callback to validate the cert manually but it is implemented as a part of the delegate. I do see that there's a method mqtt.didReceiveTrust which I assume should be used for cert validation, and I wish to use the closures approach as stated on the README page as giving an example for the didReceiveMessage methond:
Now you can use closures instead of CocoaMQTTDelegate:
mqtt.didReceiveMessage = { mqtt, message, id in
print("Message received in topic \(message.topic) with payload \(message.string!)")
}
With a weak understanding of Swift Closures, I am not able to figure out how to make that function all, so the question now becomes: how to convert that function from the delegate definition into the closure?
Converse.js successfully makes requests to Prosody bosh but the chat client never actually connects. In the console I can see it hitting the bosh endpoint and after each request it outputs to the console:
"Server did not yet offer a supported authentication mechanism. Sending a blank poll request."
I can hit the bosh endpoint from my browser as well, the proxy pass appears to be working as intended and bosh is running and responding to requests.
Any insight is much appreciated.
I came across this issue as well while using the fullpage demo. The problem was because Prosody was forcing encrypted authentication only for client side.
I recommend going into the config file /etc/prosody/prosody.cfg.lua
Look for the code
-- Force clients to use encrypted connections? This option will
-- prevent clients from authenticating unless they are using encryption.
c2s_require_encryption = true
By default for me this was set to true, change this to false
c2s_require_encryption = false
save it and reboot Prosody
systemctl restart prosody
you could also do
prosodyctl restart
The error message is quite clear. Prosody is not offering a SASL authentication mechanism supported by Converse.
By default Converse supports SCRAM-SHA1, DIGEST-MD5 and PLAIN.
Your XMPP server needs to support one of these.
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"
I am trying to enable BOSH connection over Openfire so that i can create a XMPP client over a web. curretly i am testing it with the strophe.js.
the problem is when i try to fire following url in a browser i am getting
http://www.mydomain.com:7070/http-bind
following error
HTTP ERROR 400
Problem accessing /http-bind/. Reason:
Bad Request
Powered by Jetty://
here is my server setting , i saw few threads but they arent helpful
update
i have made a connection using strophe but i am getting following error in browser trance
its now working in my system.
i think your error encountered may actually be a configuration issue with the openfire.
It is designed to reply with HTTP 400 Bad Request if there is no element in the request. You can test this yourself by providing a element in your query.
Try the following URL in your browser:
http://www.servername:7070/http-bind/?<body rid="1"/>
In your update Strophe is sending OPTIONS HTTP requests which means that it is negotiating cross domain communication. Requests are painted red which means that this is failing for some reason. Probably misconfiguration.
There is a nice article about that here: http://metajack.im/2010/01/19/crossdomain-ajax-for-xmpp-http-binding-made-easy/
Otherwise, when Strophe does its regular BOSH communication it uses POST method.
Your setup is correct. The page the browser displays to you is also normal. Openfires BOSH component is not designed to work in a Browser with HTTP GET, only with BOSH clients like strophe. Try to connect with strophe.
You should use proxy to repost the request to the openfire server . Because, the js post cannot support cross domain.
Notes:
1.I use jsjac , but I think it's not important .
2.If you sure your config is right , please restart you openfire server . It's my experience .
If server is properly configured it should display
HTTP ERROR: 404
Problem accessing /http-bind/. Reason:
Not Found
Powered by Jetty://
The Bad Request was gone when I uninstall and reinstall Openfire as in
here.
Below works for me, i am pinging the openfire server after some interval so, clients remains alive...
i just append "/?<body rid='1'" with the server name and i don't have 400 bad request error.
XMPPconnection.sendIQ($iq({ to: XMPPserver+"/?<body rid='1'/>", from: CurrentUserJID, type: "get" }).c('ping', { xmlns: "urn:xmpp:ping" }));
I'm trying to connect to gmail using a simple java program (like this one). But my question is:
Is there a way to do this with encrypted password and not the real password, for security reasons of course!! something like how we do in java-Oracle db ?
By default, the only authentication mechanism for IMAP is the LOGIN command, which takes an unencrypted username and password. You can add an encryption layer on top of it, either by connecting via IMAPs or starting a TLS layer via the STARTTLS command, but it still requires the client to know the cleartext password.
A server can optionally also provide SASL authentication methods invokable via the AUTHENTICATE command. The server advertises which SASL mechanisms it supports in its response to the CAPABILITY command. For instance, if the server includes the capability "AUTH=PLAIN", the client can use the PLAIN SASL authentication method via the AUTHENTICATE PLAIN IMAP command.
Gmail supports only one SASL authentication mechanism, XOAUTH:
C: 1 capability
S: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
SASL-IR AUTH=XOAUTH
S: 1 OK Thats all she wrote! dv32if2169247ibb.17
XOAUTH is a nonstandard SASL authentication mechanism using OAuth. (The leading 'X' means it's not standardized.) Google has published a document defining the XOAUTH SASL mechanism. They've also provided a google-mail-xoauth-tools package, which includes sample code showing how to use JavaMail with Gmail via XOAUTH.