Re: self signed cert
Ah, but the man in the middle only gets one chance to mess with your cert. That is the first time you encounter the self signed cert, you trust it and it goes into your root store. So don't do that first encounter over public wifi. You could also just distribute the cert to those that need it. I know when I used a web hosting company to handle my email, I would yearly have to blindly trust the new cert. Granted I inspected it, but the mua didn't do anything to verify the cert. Now I suppose if I used Web based email, that might have been different. I'm thick skinned to feel free to tell me if I got any part of this wrong. Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 4:30 PM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 12∶34 -0700, użytkownik li...@lazygranch.com napisał: > I'm not following you here. You still have encryption with a self > signed cert, but no trust. But if you can't trust yourself, who else > can you trust? If you have a reliable way of distributing your certificate, then yes. But then you are acting as an CA, so why don't use a real one? But if you just accept whatever cert server provides you with (like most people connecting self-signed service), then you have no more protection than on unencrypted connection. > On public wifi without the self signed cert, the conversation could > be read, not to mention login credentials. Using man-in-the-middle attack, even the encrypted conversation could be read - see above scenario with accepting server provided cert. And the default configuration of jabberd2 is not to allow plain text passwords on unencrypted channel, so you cannot read the login credentials. > Take "letsencrypt" for example. Prior to adding their certificates to > my root store, I could still get encryption, provided I let my > browser go ahead. I just could trust the website identity. But you are not sure the identity. You could aswell trust the man-in- the-middle proxying your communication and posing as the website. > The Hong Kong Post Office is a CA, but I don't really trust them. ;- > ) Why? They passed the audit checking whether they reliably verify the credentials before signing certs. > But xmpp doesn't have the downgrade option. You do not need to downgrade to unencrypted channel. MITM can aswell proxy an encrypted connection on both sides decrypting/encrypting on flight. As long as clients accept self-signed certs blindly, without consulting CA registry. -- /o__ Documentation is like sex: when it is good, it is very, very good; and (_<^' when it is bad, it is better than nothing.
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 12∶34 -0700, użytkownik li...@lazygranch.com napisał: > I'm not following you here. You still have encryption with a self > signed cert, but no trust. But if you can't trust yourself, who else > can you trust? If you have a reliable way of distributing your certificate, then yes. But then you are acting as an CA, so why don't use a real one? But if you just accept whatever cert server provides you with (like most people connecting self-signed service), then you have no more protection than on unencrypted connection. > On public wifi without the self signed cert, the conversation could > be read, not to mention login credentials. Using man-in-the-middle attack, even the encrypted conversation could be read - see above scenario with accepting server provided cert. And the default configuration of jabberd2 is not to allow plain text passwords on unencrypted channel, so you cannot read the login credentials. > Take "letsencrypt" for example. Prior to adding their certificates to > my root store, I could still get encryption, provided I let my > browser go ahead. I just could trust the website identity. But you are not sure the identity. You could aswell trust the man-in- the-middle proxying your communication and posing as the website. > The Hong Kong Post Office is a CA, but I don't really trust them. ;- > ) Why? They passed the audit checking whether they reliably verify the credentials before signing certs. > But xmpp doesn't have the downgrade option. You do not need to downgrade to unencrypted channel. MITM can aswell proxy an encrypted connection on both sides decrypting/encrypting on flight. As long as clients accept self-signed certs blindly, without consulting CA registry. -- /o__ Documentation is like sex: when it is good, it is very, very good; and (_<^' when it is bad, it is better than nothing. signature.asc Description: This is a digitally signed message part
Re: self signed cert
I'm not following you here. You still have encryption with a self signed cert, but no trust. But if you can't trust yourself, who else can you trust? On public wifi without the self signed cert, the conversation could be read, not to mention login credentials. Take "letsencrypt" for example. Prior to adding their certificates to my root store, I could still get encryption, provided I let my browser go ahead. I just could trust the website identity. The Hong Kong Post Office is a CA, but I don't really trust them. ;-) For private use, self signed is fine. Note than in email, you generally set up the mta with "may encrypt". That is how the MITM hacks your email my stripping SSL then allowing a downgrade. (Neither rain nor snow nor a MITM, the mail must go through.) But xmpp doesn't have the downgrade option. Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 11:12 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Cc: Jabber/XMPP software development list Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 09∶40 -0700, użytkownik li...@lazygranch.com napisał: > I suspect you wouldn't want s2s to use a self signed cert, so > allowing two level of verification (c2s and s2s) sounds complex. You > fix one thing in software and you break something else. So, why would you allow self-signed on C2S? Why do you want to use encryption in the first place? So, no one is able to read the conversation, right? But self-signed cert does not give you this... Just a false illusion that you are protected from evesdropping. But self-signed does not protect you from man-in-the-middle attack, so basically still anyone able to tap the wire your transmission is going through is able to read it, with just slightly more effort. > I noticed the online documentation doesn't completely match the xml, > but there are enough comments in the xml that I could get close to > setting it up. It is just the certs that are confusing. Yeah. The real and up to date source of documentation are the comments in the configuration files. -- /o__ (_<^' Practice is the best of all instructors.
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 09∶40 -0700, użytkownik li...@lazygranch.com napisał: > I suspect you wouldn't want s2s to use a self signed cert, so > allowing two level of verification (c2s and s2s) sounds complex. You > fix one thing in software and you break something else. So, why would you allow self-signed on C2S? Why do you want to use encryption in the first place? So, no one is able to read the conversation, right? But self-signed cert does not give you this... Just a false illusion that you are protected from evesdropping. But self-signed does not protect you from man-in-the-middle attack, so basically still anyone able to tap the wire your transmission is going through is able to read it, with just slightly more effort. > I noticed the online documentation doesn't completely match the xml, > but there are enough comments in the xml that I could get close to > setting it up. It is just the certs that are confusing. Yeah. The real and up to date source of documentation are the comments in the configuration files. -- /o__ (_<^' Practice is the best of all instructors. signature.asc Description: This is a digitally signed message part
Re: self signed cert
I painfully made a self signed cert for my email with the intermediate step of makeling a cert that mints the final cert. Basically a three step process. Do I remember how I did this? Nope. But I should be able to do it again. I will work on this a bit. But if you want to change the code, I'm more than willing to build the binary again. Email works just fine with self signed certs, but you have additional schemes to prove your identity, though few email service providers bother. (SPF and DKIM prove you control the server/DNS and have open source programs to do this. But of course a cert from an authority does that in one step.) I suspect you wouldn't want s2s to use a self signed cert, so allowing two level of verification (c2s and s2s) sounds complex. You fix one thing in software and you break something else. I think the best scheme is for me to do the three step self signed cert. Obviously I will document this if I get it to work, replacing the old documentation. I noticed the online documentation doesn't completely match the xml, but there are enough comments in the xml that I could get close to setting it up. It is just the certs that are confusing. Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 9:17 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Cc: Jabber/XMPP software development list Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > jabberd2 version(2.3.6) > I followed these instructions: > https://github.com/jabberd2/jabberd2/wiki/InstallGuide-OpenSSLConfigu > ration > [...] > SM : sx (ssl.c:405) secure channel not established, handshake in > progress > SM : sx (ssl.c:59) verify error:num=18:self signed > certificate:depth=0:/C=US/ST=state/L=city/O=none/OU=none > /CN=mydomain.org/emailAddress=webmas...@mydomain.org > I guess I could catch X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT (18) in SSL_CTX_set_verify callback and pass the cert through, but I'm ambivalent about it... We should really discourage use of self-signed certificates. On the other hand, it really speeds-up test deployments. Maybe have it as an opition, to enable if you really-really need to use self-signed certificates? What do you think? -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > jabberd2 version(2.3.6) > I followed these instructions: > https://github.com/jabberd2/jabberd2/wiki/InstallGuide-OpenSSLConfigu > ration > [...] > SM : sx (ssl.c:405) secure channel not established, handshake in > progress > SM : sx (ssl.c:59) verify error:num=18:self signed > certificate:depth=0:/C=US/ST=state/L=city/O=none/OU=none > /CN=mydomain.org/emailAddress=webmas...@mydomain.org > I guess I could catch X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT (18) in SSL_CTX_set_verify callback and pass the cert through, but I'm ambivalent about it... We should really discourage use of self-signed certificates. On the other hand, it really speeds-up test deployments. Maybe have it as an opition, to enable if you really-really need to use self-signed certificates? What do you think? -- smoku @ http://abadcafe.pl/ @ http://xiaoka.com/ signature.asc Description: This is a digitally signed message part
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 06∶22 -0700, użytkownik li...@lazygranch.com napisał: > So the documentation on generating a self signed cert is not > correct. It is (for the lack of better word) ancient. Unfortunately, there is no one willing to work on improving it. > Isn't the key generated in that document technically the root CA? I think so. -- /o__ Q: What is the difference between a duck? (_<^' A: One leg is both the same. signature.asc Description: This is a digitally signed message part
Re: self signed cert
So the documentation on generating a self signed cert is not correct. Isn't the key generated in that document technically the root CA? Original Message From: Tomasz Sterna Sent: Tuesday, May 3, 2016 5:12 AM To: jabberd2@lists.xiaoka.com Reply To: jabberd2@lists.xiaoka.com Subject: Re: self signed cert W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > How exactly do I specify the cachain for a self signed cert. You need to put your root CA used to sign the cert to the CA certs store specified in 'cachain' option. This is to encourage deployments to stop using self-signed certs, of questionable security, and instead get a real cert. You can get real, widely accepted certs for free. > I get openssl error 18 meaning it can't be verified. Setting > verify-mode='0' didn't help. verify-mode sets how should the server verify client provided certificates. 0 (SSL_VERIFY_NONE[1]) is the default. [1] https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html -- /o__ (_<^' I respect faith, but doubt is what gives you an education.
Re: self signed cert
W dniu 03.05.2016, wto o godzinie 02∶12 -0700, użytkownik li...@lazygranch.com napisał: > How exactly do I specify the cachain for a self signed cert. You need to put your root CA used to sign the cert to the CA certs store specified in 'cachain' option. This is to encourage deployments to stop using self-signed certs, of questionable security, and instead get a real cert. You can get real, widely accepted certs for free. > I get openssl error 18 meaning it can't be verified. Setting > verify-mode='0' didn't help. verify-mode sets how should the server verify client provided certificates. 0 (SSL_VERIFY_NONE[1]) is the default. [1] https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html -- /o__ (_<^' I respect faith, but doubt is what gives you an education. signature.asc Description: This is a digitally signed message part
self signed cert
freebsd 10.2 jabberd2 version(2.3.6) I followed these instructions: https://github.com/jabberd2/jabberd2/wiki/InstallGuide-OpenSSLConfiguration other than renaming server.pem to jabber.pem since I had originally put that in the XML files. In the c2s.xml MYDOMAIN>ORG Pulling some lines out of the debug with the usual sanitation to keep out of the search engines: C2S : Tue May 3 08:54:56 2016 authreg.c:80 preloaded module 'mysql' (not initialized yet) SM : sx (ssl.c:992) Restricting TLS ciphers to !aNULL:!eNULL:!EXP:ALL:!EXPORT:!aNULL:!eNULL:!SSLv2 SM : sx (ssl.c:1021) No CA chain specified. Loading SSL default CA certs: /etc/ssl/certs SM : sx (ssl.c:405) secure channel not established, handshake in progress SM : sx (ssl.c:59) verify error:num=18:self signed certificate:depth=0:/C=US/ST=state/L=city/O=none/OU=none /CN=mydomain.org/emailAddress=webmas...@mydomain.org How exactly do I specify the cachain for a self signed cert. I get openssl error 18 meaning it can't be verified. Setting verify-mode='0' didn't help.
