Little Snitch and HTTPSecureSocket

I am not too familiar with hacking tools.

What happens with LittleSnitch and SSL ? What are the risks of it getting to the data being exchanged when https is used ?

LittleSnitch is a firewall. Nothing to do with SSL.

If your SSL client verifies certificate, domain and doesn’t trust anything, you can be secure.

[quote=268352:@Christian Schmitz]LittleSnitch is a firewall. Nothing to do with SSL.

If your SSL client verifies certificate, domain and doesn’t trust anything, you can be secure.[/quote]

Basically I don’t want people to snoop what I am exchanging with the web service. Thank you.

Well, I use for that stuff my CURL plugin.

There I can provide the SSL certificate from the target server and just accept that one certificate.
That is calle certificate pinning. So while CIA could make their own certificate for my domain, I would no trust it.

@Michel Bujardet if you don’t have it in your Mac download it and test it (there is a 30 days full demo).
LittleSnitch is a firewall with many flags but no hacking tool,the LittleSnitch give you the opportunity to block incoming-outgoing ports from internet-network…

[quote=268361:@Loannis Kolliageorgas]@Michel Bujardet if you don’t have it in your Mac download it and test it (there is a 30 days full demo).
LittleSnitch is a firewall with many flags but no hacking tool,the LittleSnitch give you the opportunity to block incoming-outgoing ports from internet-network…[/quote]

And it’s AWESOME btw :wink:

Thank you.

What you’re talking about is a packet sniffer. And yes, for basic, insecure http, someone will be able to spy on your traffic (I’m guessing this is for your trial-version license from the other thread). The solution Christian provided is a good one, short of going to the great lengths to write your own encrypted transfer protocol (which is always wise to avoid, because unless you’re an encryption specialist it’s very easy to make a tiny error that makes your encryption virtually useless!).

You could also use the new httpsocket in secure mode. With certificate validation on, you’d be able to tell if someone set up a man-in-the-middle attack because you’d get an exception.

[quote=268350:@Michel Bujardet]I am not too familiar with hacking tools.

What happens with LittleSnitch and SSL ? What are the risks of it getting to the data being exchanged when https is used ?[/quote]
In one case I added an additional level of security by sending encrypted json strings to a webservice, and back. Like this the webservice can talk to that one client only. While client and service do communicate over https, they do not solely depend on it for encryption.

Openssl has been hacked before (“heartbleed”), so it could happen again.

I use LittleSnitch in a daily basis… as an anti-hacking tool! :smiley: It let’s me know what apps are trying to do weird things… what addresses:ports are using and, in some cases, inspect the traffic. I think it’s one of the best tools anyone can have.

Javier

I use LittleSnitch too. I want to know what apps are communicating to some server somewhere sending data and decide if I should let them or not.
Basically because I’m curious. I want to know whats going on in my system…so most connections are set to “Allow” :slight_smile:

I use it as an AdBlocker too :slight_smile:

Indeed. If it was too easy to crack, the evaluation could become a freeware !

Great. I will do that. Thanks.

I will make sure to tell users the evaluation app needs the Internet.

Yes, exactly :wink: Little snitch could block your app from communicating, but it can’t see the traffic. A packet sniffer can see the traffic but if it’s HTTPS then it’s already encrypted before the packet sniffer will see it so they will see nothing but packets of garbage if they try to read it.

A “man in the middle” attack is where I fake out who you think you’re connecting to, so you make a secure connection to MY app, which since it’s negotiated the certificate and SSL with you it can now decrypt your traffic. Then that app opens a connection to where you really want to connect via another SSL channel and forwards on your data so that it appears that you’re connected to them even though it’s potentially copying all the decrypted data before re-encrypting it and sending it on. There are tools to do this and I’ve heard of people setting up fake access points in airports and such to try to snag peoples bank signons or cc numbers or something. The problem with this is that the certificate they are using to encrypt the channel to you either does not belong to the real host, or it’s a copy of the one from the real host and in either case you’ll get a notice in your browser that the cert is invalid. If you turn on certificate validation in the xojo class it will throw an error if the cert doesn’t match up properly and you can stop the communication and send errors. That requires a signed certificate though because it has to be able to connect to the signing company and verify the cert, these cost some money and must be regularly updated and such. A self signed certificate will stymie someone with just a packet sniffer as the communications are still encrypted, the downside is that they can’t be verified by a third party and so you can’t trap a man in the middle attack the same way. I believe, though I am not certain, that you can still trap the certificate not being trusted yet and if you think you already trusted this one then something has changed and you’re potentially being listened in on.

I personally would avoid double encrypting things. It’s possible to make the encryption worse and not better, or so I have been led to understand. Much of the lower level details of encryption are a bit beyond me :wink: Yes, SSL could get hacked again and they could find another bug in it or some such. But it is widely used by so many people that bugs and problems that are found tend to get fixed fairly quickly and a lot of people are looking for those bugs. That doesn’t mean there won’t ever be a period of time when you’re vulnerable, but to think that you could do a better job than the teams of people working on that is probably not realistic.

That doesn’t apply if you’re only communicating between your own apps and can actually install keys on both machines. In a circumstance as that you can use some other encryption for the packets and manually move the keys around and update as necessary. You can do something very secure that way with the encryption plugins available from MBS and others, but it’s far more difficult to manage and maintain than using the standard SSL socket stuff and I’m not sure that the increase in security is significant enough to warrant such an exercise for any but the most unusual circumstances.