Port 5552 = SSL?

Hello,

i am 99% sure that port 5552 is using SSL but i want to be sure: i configurated in my openfire configuration everywhere that ssl is required.

I made a tshark dump and everything seems to be encrypted.

But: In site client-connections-settings.jsp stands:

SSL Enabled: Yes

Client SSL Port: 5223

I connect over port 5222 - as i understood 5223 use the old version of ssl and 5222 the new version, right?

But there stands in the log:

Started plain (unencrypted) socket on port: 5222

I think this means, that both can be accepted if openfire is configurated to accept both? But in my case i accept SSL only so there is no unencrypted traffic on port 5222.

Is it correct that port 5222 uses SSL when i set “Client Connection Security” to “Required”?

On wireshark i couldnt read any message when SSL was required. I made then a test and disabled SSL and i could read everything. I just want to be sure that i done everything correct and the traffic is encrypted.

Sorry for my stupid question.

I hope you understand my bad english

Thanks!

SSL is absolute, so use TLS version 1.2 otherwise people might read your secure socket data. If you want to use SSL use self signed certificates so do not let anyone else store your master key. Use SSL 256bits or 512bits only.

Use OTR only for messaging if your messages need to keep private.

Thanks for your tips, but this answers not my question.

The XMPP stream starts always unencrypted over a plain socket. If TLS is required by Openfire it will send a during the stream negotiation process over the plain socket. If it is optional, it sends only

If the client wants to use TLS it answers with . Then the server responds with .

And only then the TLS handshake begins and the socket connection is upgraded to a secure socket connection (over the same port). The stream is then also restarted in order to work with a fresh encrypted stream.

So "Started plain (unencrypted) socket on port: 5222" is quite normal as every connection starts unencrypted.

Everything I said is also described in the XMPP specification.

what? self-signed ssl certs are not advisable for a lot of reasons including no client will trust it by default, leading to headaches for whoever is administering the server. If it’s only you and maybe some buddies using it, then sure, go for a selfie, otherwise, do yourself a favor and get a real ssl cert.

There is no vulnerbility from having some other entity (like Godaddy, Verisign, Geotrust, etc) sign your CSR. No data is exposed from that process that could compromise your server. If it did, SSL would be horribly broken.

what? self-signed ssl certs are not advisable for a lot of reasons including no client will trust it by default, >leading to headaches for whoever is administering the server. If it’s only you and maybe some buddies using >it, then sure, go for a selfie, otherwise, do yourself a favor and get a real ssl cert.

Real ssl certs? And what are those then? Are they more real than a self signed?

Are they more secure? Please explain.

How do you think NSA sniffs SSL connections by cracking them or getting info about

it from cert orgs?

I advice you to visit the wikileaks pages and do some research about SSL and its security

before making such bold claims…

And what are the other reasons not to use self signed certs than?

I would trust my self signed SSL more…

But i might be paranoid.

OK, there’s a few things to address here, I’ll do my best without going down the NSA rabbit hole. (believe me, I’m probably just as upset over the NSA revelations as you are, if not more).

All SSL certs are “real” in the sense that they are an SSL cert. Obviously… – however, a self signed cert is not “trusted” by any device, program, operating system, computer, phone, etc on this planet by default. This is because your certificate is not “signed” by a globally “trusted” Certificate Authority. The CA’s basically are vouching that your server is who it says it is. That’s all.

If you use a Self Signed cert, basically your cert tells anyone who is connecting via a program, webpage, etc, that your server is who it says it is, because it says so. Basically, you’d have to take the server’s word that it’s the actual server you think you are connecting to. This is horrible sevurity, and is the reason why self signed certs are not used in production applications unless the entire environment is controlled, ie. a corporate network running some intranet applications that are internal-facing only – because the admins can go around to every computer and download the self signed cert and install it in the computer’s “trust store”. Obviously a lot of manual work… and it adds zero additional security.

I want to repeat, a self signed cert is not more secure than a CA signed cert. In fact, they are identical. The only difference between them, is the self signed cert isn’t trusted by anything, whereas the CA Signed cert is usually guarunteed to be trusted by 99% of everything.

A CSR (needed to get a signed cert from a CA) does not disclose any information about your server other than it’s hostname, and your company information (name, department, location, etc).

The NSA is not capable of breaking SSL certs that are of 128bits and more (just about all of them are). The NSA has been brute forcing lesser-secure things, yes, but SSL is not broken (otherwise the internet would be in a HUGE panic). Yes, TLS is the next iteration of web security and I do advise making a switch when possible… but also realize there are problems with TLS such as not all things can negotiate connections yet over TLS. Old browsers and programs simply don’t “speak” TLS yet.

Even if CA’s were malicious in nature (some may be, who knows), what could they really do that would compromise your security? Give the NSA your name and business name and address? That’s hardly a secret if you are a company anyways. Give the NSA your CSR? Great, the NSA can generate a cert in your name, but it won’t work and wont be trusted unless they hijacked your DNS and pointed it to their [spoofed] servers. See, the creators of SSL thought of all these things already, since there is always a large interest for someone to break SSL (not just the NSA are interested in breaking SSL, since SSL was created people have tried to break it).

In a long winded conclusion – don’t worry so much about this. if you are running a public service of some kind, you will need to get a properly CA Signed cert, otherwise you won’t have users/customers for very long. If you are doing a home project, something for a few friends, or in a completely controlled environment such as a corporate network, then a self signed cert is ok. As with most things, there is a proper time and place for them.

bas wrote:

But i might be paranoid.

Paranoid suspecting that he might be paranoid? You are in trouble

Real certs are stronger by assumption that certification authorities can be trusted. As nobody is standing behind your self-signed cert, where is nobody to “ask” if you can trust given certificate and if it hasn’t been altered by a man in the middle. I don’t know much about the technical stuff about signing, checking the chains, etc. But i think this is the main reason. Of course, if you are paranoid, you can’t trust anything, even your own selfie cert Though, not speaking about NSA even, there are known recent examples when CAs are hacked and hackers generate false certificates and use them for their schemes. Nothing can guarantee 100% security.

Jason wrote:

because the admins can go around to every computer and download the self signed cert and install it in the computer’s “trust store”. Obviously a lot of manual work…

Admins never go around every computer, they are too lazy GPO can deploy certificates automatically. We do this, and we use self-signed certs internally. Though, i still have to do a lot of foot work daily… Not a high level admin yet

Lol, we do it via GPO too. Didn’t want to get into that in this discussion though, since that usually only applies to a corporate network of some kind. I was trying to make a point that usuing a selfie becomes a lot of management work, uneccessarily.

– The best admins, are the laziest.

Well, that depends. We wanted to use more secure email (POP3 is already SSL, but SMTP isn’t). So we asked our mail hoster and they purchased the cert. But Outlook refused to trust it (RapidSSL cert). So… still using non-SSL SMTP…

POP3!!! Lol… IMAP for the win!

It’s possible your outlook version did not, has not, or will not receive an update to include the RapidSSL CA server(s). RapidSSL is a big name, so I’m suspecting a similar issue to that with Godaddy SSL certs that are using SHA-2 instad of SHA-1…Basic gist is they may have a newer CA server at RapidSSL that they have not added to all the common trust-stores as-of yet. Your cert may have been signed by the newer server.

http://support.godaddy.com/groups/ssl-certificates/forum/topic/ssl-cert-not-reco gnized-by-java/?pc_split_value=2

I had the same problem, but with Godaddy. in the case of godaddy, they had added their newer CA server to most browsers and other things, but left out Java… resulting in all java programs not trusting (and in some cases refusing to connect) to services, unless you manually added the CA to your trust store (not something you can do easily with a deployed public application).

I rather use my own self signed cert for personal usage. If you want people to “trust” your website

you will have to have a signed cert by some “trusted” company.

We run our XMMP server and our IronChat on a private server that is only accesable for

member so there is no need for a signed cert from a so called “trusted” entity.

Eyedropping of SSL traffic is something allmost every govement agency is doing these days

and i would not be suprised if 128 bits SSL has already been cracked. Computing power is

multiplying almost every year and quantum computing is looking around the corner.

SSL traffic than is stored now can be accessed later…that is why i advice people not only to use 1024 bits

private keys but also use OTR for all their business communication.

i would recommend to @Manuel Laumb to read this article:

http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html

honestly, it sounds like you should unplug the ethernet cable

In your scenario, your “members” would have to go and specifically tell their program/browser to ignore security checks when connecting to your service. So, you are actually reducing your security because you are training members to blindly click through the ssl warning message… so in the future, if someone DID spoof your server, you are making their job a lot easier - your users will get an SSL warning that the cert is not trusted, they will blindly click through it and give the attacker all their data.

In an attempt to build taller walls, you burned down your castle.

Also, it is not possible to “evesdrop” on SSL connections. It’s by design - they are encrypted and to date, have not been broken by any government agency or individual (seriously, it hasn’t. The internet would be in chaos if something so central to the internet ceased to function). You can surely collect SSL data, (which the NSA is doing), but what can you do with a bunch of highly encrypted packet data?

Well, you can try to decrypt it. Encryption is not and never was meant to be always secure… the point of encryption is to make it infeasible with current technology and computing power, to crack it. We have only recently been able to break 64 bit encryption, let alone 128bit or 256, 512, etc. So by the time we can easily crack 128bit encryption, the data it was protecting will likely not be relevant anymore (statute of limitations run out, dated info, old passwords not in use, etc).

Unless there is a Man-in-the-middle attack or similar, which I already mentioned you made easier for the attacker, then you are ok with a CA signed cert.

Just to be straight up with you – self signed certs are almost always used as a cost savings, not for any technical or security related reason. But, since you can pickup a Godaddy SSL cert for as low as 12 USD, then it’s not much of a savings anymore given the added administration overhead it implies.

But: In site client-connections-settings.jsp stands:

SSL Enabled: Yes

Client SSL Port: 5223

I connect over port 5222 - as i understood 5223 use the old version of ssl and 5222 the new version, right?

But there stands in the log:

Started plain (unencrypted) socket on port: 5222

I think this means, that both can be accepted if openfire is configurated to accept both? But in my case i accept SSL only so there is no unencrypted traffic on port 5222.

This is my understanding as well. All connections are on this port unless you are connecting via older SSL versions. I suspect the UI was never updated to reflect that. It should probably show the TLS (SSL v3) port as 5222 and SSL v1,v2 as 5223.

As CSH mentioned, the opening connection negotiation is always unecrypted as that is how TLS works.