|
pr0zac posted:You guys know It takes all of 5 minutes to decompile an iOS app and/or mitm the traffic to check claims of backdooring or logging right? Objective-C doesn't even obfuscate symbols, any idiot can do it. Whatsapp isn't peer to peer afaik. The underlying protocol is basically jabber. Given that it goes through servers run by Facebook, inspecting the source locally is unlikely to tell you much useful about any logging.
|
#
?
Apr 22, 2016 10:04
|
|
|
|
| # ? May 10, 2024 17:40 |
|
|
feedmegin posted:Whatsapp isn't peer to peer afaik. The underlying protocol is basically jabber. Given that it goes through servers run by Facebook, inspecting the source locally is unlikely to tell you much useful about any logging. Except that the encryption happens locally, and is (auditably) end-to-end. E: metadata about message and voice traffic is visible, if that's what you mean. Subjunctive fucked around with this message at 14:45 on Apr 22, 2016 |
|
#
?
Apr 22, 2016 13:02
|
|
|
I wouldn't have a clue what to look for in a bunch of decompiled c, so the basis of my assumption is sociological: Facebook is part of the status quo, and makes a pretty penny from being there. Why would they want to upset that balance by offering 'true' unbreakable end to end private messaging and also open up possibilities where they have to defend themselves against gov/FBI/yadda?
|
|
#
?
Apr 22, 2016 15:24
|
|
|
DeaconBlues posted:I wouldn't have a clue what to look for in a bunch of decompiled c, so the basis of my assumption is sociological: Facebook is part of the status quo, and makes a pretty penny from being there. Why would they want to upset that balance by offering 'true' unbreakable end to end private messaging and also open up possibilities where they have to defend themselves against gov/FBI/yadda? Well if the encryption is truly unbreakable by themselves after the fact and no logs of the data or keys are kept then that is all the defense they need. If you can get experts to testify before a judge that something is truly impossible then the judge will generally accept that as a good reason to not issue an order to do that something or as a good reason for not complying with such an order. Now that doesn't stop the government from forcing them to implement logging of the keys or data with a law or court order or something. But that would only help with all transactions from that point onward. Older stuff would be safe forever. With Startcom and Lets Encrypt handing out trusted certs for free left and right there is no reason not to encrypt literally everything on the internet with solid not-breakable-after-the-fact crypto. TLS 1.2, ECDHE, and AES-GCM. Done. In fact if I go to facebook.com in Firefox this is the exact cipher suite they are using. Trendy crypto nerds can use ChaCha20 and Poly1305. They even have have TLS_FALLBACK_SCSV enabled and a proper HSTS header and HSTS preloading in all major browsers. Baring some secret government warrant/fisa court order I would say that they are pretty serious about crypto. Now if only there was some group handing out trusted ECDSA certs for free I would be a happy happy nerd. Antillie fucked around with this message at 16:22 on Apr 22, 2016 |
|
#
?
Apr 22, 2016 15:49
|
|
|
Facebook already says no to law enforcement requests every day. My team has a "come back with a warrant" doormat in our area. We've gone to court to limit what LE can subpoena.
|
|
#
?
Apr 22, 2016 15:56
|
|
|
DeaconBlues posted:I wouldn't have a clue what to look for in a bunch of decompiled c, so the basis of my assumption is sociological: Facebook is part of the status quo, and makes a pretty penny from being there. Why would they want to upset that balance by offering 'true' unbreakable end to end private messaging and also open up possibilities where they have to defend themselves against gov/FBI/yadda? In 2014 Facebook setup a hidden service which makes their website accessible via Tor. By doing this FB increased the number of people using their service, especially in countries with restrictive government censorship practices. FB make money through the number of people using their service. This is why they setup that Interner.org outfit. If they think that they can attract more users to their service by implementing end-to-end encryption then they will more than likely do it. The quality of said encryption is moot as anyone who actually wants end-to-end encryption would avoid using a third-party service. Basically I'm not really sure what your point is. Also what Subjunctive said.
|
|
#
?
Apr 22, 2016 16:06
|
|
|
I was responding to the replies suggesting that it may be stupid to question whether the service is completely private. Thanks for the info regarding Facebook setting up philanthropic services.
|
|
#
?
Apr 22, 2016 16:27
|
|
|
It is definitely not stupid to question if a service really is completely private. In fact I would say that it would be stupid not to. I haven't examined WhatsApp at all but my cursory look at facebook's web site gives me the impression that they know what they are doing and are serious about doing crypto right. I would hope that this same mentality crosses over to the group responsible for the WhatsApp crypto. Does it prove anything about WhatsApp? No. But its an encouraging fact none the less. Antillie fucked around with this message at 17:38 on Apr 22, 2016 |
|
#
?
Apr 22, 2016 17:36
|
|
|
Antillie posted:my cursory look at facebook's web site gives me the impression that they know what they are doing Same - I hadn't heard of Facebook before but after a quick poke around their home page they get my seal of approval
|
|
#
?
Apr 22, 2016 18:47
|
|
|
Rufus Ping posted:Same - I hadn't heard of Facebook before but after a quick poke around their home page they get my seal of approval 
|
|
#
?
Apr 22, 2016 18:50
|
|
|
Antillie posted:Well if the encryption is truly unbreakable by themselves after the fact and no logs of the data or keys are kept then that is all the defense they need. If you can get experts to testify before a judge that something is truly impossible then the judge will generally accept that as a good reason to not issue an order to do that something or as a good reason for not complying with such an order. Is let's encrypt actually worth taking the x minutes to set up? I remember ready somewhere that all having a cert from them says is "this guy has a cert from us" but doesn't actually mean/do much else. Could be wrong though.
|
|
#
?
Apr 22, 2016 19:19
|
|
|
Boris Galerkin posted:Is let's encrypt actually worth taking the x minutes to set up? I remember ready somewhere that all having a cert from them says is "this guy has a cert from us" but doesn't actually mean/do much else. Could be wrong though. What's your question? It's a SSL certificate, not Extended Validation, and does no more or less than any other SSL certificate.
|
|
#
?
Apr 22, 2016 19:26
|
|
|
Rufus Ping posted:Same - I hadn't heard of Facebook before but after a quick poke around their home page they get my seal of approval Wait! "Of Facebook" or hadn't heard "X thing about Facebook" before? I'm exceptionally curious that there exists a demographic that hasn't been subsumed by the Facebook juggernaut. Is it really only that ubiquitous inside America?
|
|
#
?
Apr 22, 2016 23:14
|
|
|
Just looked them up on Lycos and it turns out they're a pretty big deal in the US - sorry!
|
|
#
?
Apr 22, 2016 23:26
|
|
|
You guys might be interested in the Risky Business podcast. http://risky.biz/netcasts/risky-business As a non programmer I find the infosec news interesting to listen to from time to time.
|
|
#
?
Apr 23, 2016 05:45
|
|
|
Thanks. That looks interesting to a non programmer like myself. Added to my podcast player.
|
|
#
?
Apr 23, 2016 05:58
|
|
|
pr0zac posted:You guys know It takes all of 5 minutes to decompile an iOS app and/or mitm the traffic to check claims of backdooring or logging right? Objective-C doesn't even obfuscate symbols, any idiot can do it. ITT it takes an idiot 5 minutes to guarantee that a service is free of security flaws. Thousands out of work.
|
|
#
?
Apr 23, 2016 06:01
|
|
|
ItBurns posted:ITT it takes an idiot 5 minutes to guarantee that a service is free of security flaws. Thousands out of work. Yes that is what I said, whatsapp is 100% secure. You don't at all lack reading comprehension and are a genius adding massively to this conversation. To the people who're actually discussing in good faith, I'm in the middle of moving so can only phone post and my phone ate my first post already, so will try to add more later. As far as decompiling the app goes, you don't need to understand the entire functionality, just ensure the implementation of axolotl is correct and matches other known versions. Easiest way is just check the symbols and function behavior against another trusted app, for instance Signal. Considering Moxie himself did the integration I'm pretty sure it's gonna be correct though. Go look him up if you're wondering why. With regard to the network, axolotl is in fact peer to peer encryption. It's not a peer to peer connection but those are different things. The Whatsapp servers do not decrypt the traffic before passing it on because that's technically impossible. Read about public/private key encryption if you're wondering how. Someones probably yelling about encryption stripping/forwarding on key change as a possible method for Facebook to eavesdrop. This is why I said look at the traffic. Mitm two devices that haven't talked over whatsapp before. Start a chat so the initial key exchange occurs. Look at the traffic. Do the public keys sent by each client match on both sides? Then there's no eavesdropping happening. That key exchange happens once between two devices. From that point on they are never sent again and it's impossible for Whatsapp to read traffic. Watching the traffic will also let you confirm WhatsApp isn't some how sending something out of band. Whatsapp is run almost completely separately from Facebook, they aren't on the same infrastructure or even the same campus (frankly they kinda hate FB and do everything in their power to remain separate). It should be pretty obvious to see if something is going to a Facebook server directly. If you're worried about them sending stuff to whatsapp servers then forwarding to FB, watch for any weird other traffic that doesn't make it to the other client. If it's encrypted it should be pretty easy to diagnose if it's message info (is it bigger when you send a bigger message?) If you're worried that maybe they save logs on the phone then send them later, jailbreak your device and browse the file system. Or leave it mitmed for a while and review the logs. If you're paranoid enough to worry they might suddenly push an update that adds something nefarious later then just do these steps again after every update. It's easier this time cause you just need to look at the differences from the previous version. I guarantee you a few thousand other people are doing the same thing. tl;dr whatsapps encryption was put in place by one of the biggest names in crypto who's a literal anarchist that lived on a condemned sailboat for a while. There's thousands of people smarter than anyone on this forum looking for Facebook to screw this up that have dug into this stuff in depth and given it a bill of health. It's illogical to think it's not safe.
|
|
#
?
Apr 23, 2016 18:12
|
|
|
I'd be careful about challenging pr0zac on this one here because he actually knows a thing or two more about WhatsApp than most here.
|
|
#
?
Apr 23, 2016 18:24
|
|
|
OSI bean dip posted:I'd be careful about challenging pr0zac on this one here because he actually knows a thing or two more about WhatsApp than most here. no dude you don't understand the man wants us to think it's encrypted so it can ??? that it wouldn't already do over non-encrypted channels or the man knows that people who want secret conversations are totally going to click those targeted ads about the conversations they have, this is obviously an untapped market
|
|
#
?
Apr 23, 2016 18:27
|
|
|
Subjunctive posted:My team has a "come back with a warrant" doormat in our area. Can you post a picture of the doormat in your area
|
|
#
?
Apr 23, 2016 20:16
|
|
|
pr0zac posted:Yes that is what I said, whatsapp is 100% secure. You don't at all lack reading comprehension and are a genius adding massively to this conversation. As much as I like to argue on the internet and sling personal insults, I'll offer that our disagreement stems not from whether or not the encryption works in theory but rather whether or not facebook can be trusted as a steward of user privacy compared to other options available for secure messaging. In my opinion, fb is more interested in whatsapp as a means of getting data on who people are texting as a hedge against the increasingly limited amount of personal information available to them on the fb platform, even if it means they can't actually read the texts in theory. Outside of being purposefully weakened, there's also no guarantee that this information, no matter how limited, isn't being committed to bulk data collection as is likely the case with their other offerings. In the end it comes down to whether or not you trust facebook. One could argue that the fact that their business model leans heavily on systematically violating the privacy of their users lessens this trust. On the other hand, and I think we can agree here, it's more reasonable to say that the popularity of whatsapp in most markets is a result of its ability to circumvent carrier charges rather than bleeding-edge encryption. Then, for people who aren't at extreme risk of being executed or blown up by drones, it becomes a perfectly reasonable companion to its baby-and-cat-picture-sharing parent application. Adix posted:no dude you don't understand the man wants us to think it's encrypted so it can ??? that it wouldn't already do over non-encrypted channels If you were looking for feedback, the second one is a little better.
|
|
#
?
Apr 23, 2016 20:25
|
|
|
Antillie posted:ECDSA I would like to point out that the NIST curves everyone uses used some arbitrary value for the generator seed, so there's no telling if the NSA tampered with them or not. Until this draft becomes an RFC or TLS 1.3 comes out and Curve 25519 support becomes mainstream, you're better off using RSA.
|
|
#
?
Apr 25, 2016 01:57
|
|
|
dpbjinc posted:I would like to point out that the NIST curves everyone uses used some arbitrary value for the generator seed, so there's no telling if the NSA tampered with them or not. Until this draft becomes an RFC or TLS 1.3 comes out and Curve 25519 support becomes mainstream, you're better off using RSA. lol check out this guy that thinks the US gov't is spending billions of dollars in a multi-faceted effort to sustain a pervasive domestic surveillance program take off that tinfoil hat lol
|
|
#
?
Apr 25, 2016 02:01
|
|
|
dpbjinc posted:I would like to point out that the NIST curves everyone uses used some arbitrary value for the generator seed, so there's no telling if the NSA tampered with them or not. Until this draft becomes an RFC or TLS 1.3 comes out and Curve 25519 support becomes mainstream, you're better off using RSA. Curious: how do you think the NSA has tampered with them?
|
|
#
?
Apr 25, 2016 05:38
|
|
|
OSI bean dip posted:Curious: how do you think the NSA has tampered with them? ECSDA relies on a curve as a pseudorandom number generator, basically. Both parties pick a point on the curve and share the outputs. By design, it's easy to reverse one point if you know the other, but it's computationally difficult to reverse both points. That is, assuming the curve is truly random. There was a method known (patented) at the time where if instead of picking the curve randomly you generate it yourself from some factors, then you can trivially reverse any message on that curve. When the NIST were putting out the draft standard for ECDSA, the NSA arbitrarily stepped in and said "use this curve", with no explanation. It could potentially be a kleptographic attack, where unless someone knew those factors it would be impossible to break. Sometimes in the past the NSA has strengthened the NIST algorithms. For example, they used advanced knowledge of differential cryptanalysis to strengthen the S-boxes in the DES encryption algorithm, without revealing what they had done until 20 years down the road when someone else figured out the technique. One thing that's come out recently is that not all curves are created equal. Some are much easier computationally than others, so it's possible it's something like that. Or it could be both. http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/2/ What's more, they also bribed at least one large crypto provider in the business world to use ECDSA with this curve as the default... http://mobile.reuters.com/article/idUSBRE9BJ1C220131220 Paul MaudDib fucked around with this message at 06:23 on Apr 25, 2016 |
|
#
?
Apr 25, 2016 06:08
|
|
|
The NYT had documents (which they didn't publish wholesale) supporting the claim that the NSA had messed with at least one of the curves, as part of Bullrun.
|
|
#
?
Apr 25, 2016 06:19
|
|
|
OSI bean dip posted:Curious: how do you think the NSA has tampered with them? I'm sure I saw (maybe it was on numberphile) that the seed they'd suggested allowed them to potentially decrypt things used by it.
|
|
#
?
Apr 25, 2016 07:03
|
|
|
Also related to NSA subversion of cryptosystems: http://www.cryptomuseum.com/crypto/philips/px1000/nsa.htm
|
|
#
?
Apr 25, 2016 19:13
|
|
|
Well the days of RSA are numbered even if only for performance reasons. The super common 2048 bit RSA keys used by most https web sites these days only provide about 112 bits of effective security. That's enough, but it won't be enough forever (good till about 2030 probably). The problem with RSA is that to get a linear increase in effective security you have to increase the key size exponentially. If we go up to 3072 bit RSA keys for 128 bits of effective security then RSA key exchange slows down almost to ECDHE key exchange performance levels. If we increase the key size further to 4096 bit then ECDHE ties RSA for speed. The problem with RSA is that it does not scale well from a performance perspective so RSA in general has a finite lifetime in the TLS ecosystem. Hopefully this will encourage people to migrate to ECDSA certificates as ECDHE_ECDSA is actually ~29% faster than ECDHE_RSA when RSA is using a 2048 bit key and ECDSA is using the effective security equivalent. As the key size increases the performance lead of ECDHE_ECDSA only gets larger at an exponential rate. As for the NSA having tampered with the curves... I am both optimistic and paranoid. Optimistic that they in fact strengthened them like they did with DES back in the day. There was a similar "They backdoored it! Don't use DES!" reaction back then as well. However I am not naive, they may very well have done something sneaky. So I push for people to adopt ECDHE_ECDSA now. Just getting devices upgraded to support ECDHE_ECDSA at all is a HUGE task by itself. Often you are jumping major versions on your web server software/server OS/load balancer firmware/firewall firmware and the upgrade is not a trivial thing. But once you are in the major version train that supports ECDHE_ECDSA adding new curves via a patch or minor point release is usually pretty trivial. Reissuing certificates with a new curve also isn't a big deal. So my mantra is to upgrade to ECDHE_ECDSA now, then, if needed, add better curves as they become available. Antillie fucked around with this message at 22:04 on Apr 25, 2016 |
|
#
?
Apr 25, 2016 21:33
|
|
|
Also, I specifically mentioned Curve25519 as a response to that exact issue. The number it uses was chosen because it's the smallest number that performs well for its security level. It's already used in OpenSSH, and it will be in TLS 1.3 alongside the NIST curves.
|
|
#
?
Apr 26, 2016 04:50
|
|
|
Boris Galerkin posted:Is let's encrypt actually worth taking the x minutes to set up? I remember ready somewhere that all having a cert from them says is "this guy has a cert from us" but doesn't actually mean/do much else. Could be wrong though. considering x=about 3, it's pretty brain-dead easy. Just remember to automate your renewals.
|
|
#
?
Apr 26, 2016 16:21
|
|
|
For the people asking about learning infosec, I think you could do a whole lot worse than reading through these: https://www.humblebundle.com/books/no-starch-hacking-books There are some stinkers on there (lol bitcoin, zombies), but a lot of the books are really good and it's hard to beat 15 bucks for the set.
|
|
#
?
Apr 27, 2016 19:36
|
|
|
Anyone a SIEM analyst/administrator here? If so what solution do you use and do you like it? We currently use Qradar but with some planned business expansion we're gonna have to shell out some big bucks to keep up with EPS and FPS so my boss gave me the ok to look around at other options. Honestly my dream would be a cloud based service that we could refine the alerts and thresholds while someone else does the daily stuff, cause after 2 years I am about tired of SIEM work and how obtuse it can be when trying to accomplish stuff.
|
|
#
?
Apr 27, 2016 22:17
|
|
|
FlyingCowOfDoom posted:Anyone a SIEM analyst/administrator here? If so what solution do you use and do you like it? We currently use Qradar but with some planned business expansion we're gonna have to shell out some big bucks to keep up with EPS and FPS so my boss gave me the ok to look around at other options. Not-quite-a-SIEM-but-almost-good-enough but Splunk has a cloud solution.
|
|
#
?
Apr 27, 2016 23:03
|
|
|
OSI bean dip posted:Not-quite-a-SIEM-but-almost-good-enough but Splunk has a cloud solution. Splunk can be difficult to set up to pull in data from various logtypes, and massaging it correctly so it doesn't run the peg the CPU by indexing all the time, but once it's going it goes great especially when running correlations. I have not used/configured it, but I heard FireEye TAP works really well. Make sure to research and include the costs of pushing your logs/events into the cost. If you generate lots of events and want to push them all to the cloud, it can wipe out the savings.
|
|
#
?
Apr 27, 2016 23:16
|
|
|
EVIL Gibson posted:Splunk can be difficult to set up to pull in data from various logtypes, and massaging it correctly so it doesn't run the peg the CPU by indexing all the time, but once it's going it goes great especially when running correlations. Learning regular expressions makes Splunk bearable, but you are correct that the data collection part is really the chore. The nice thing about Splunk is that it's useful for other things. We've been using it in a DFIR setting as of late as in taking data from FireEye HX outputs and then using that to compare machines. I rarely say nice things about specific vendors but Splunk is the only product I've ever used that I can actually stomach suggesting its use. It's useful if you decide to use it alongside an actual SIEM because you can forward the data off from that and just use Splunk as your collection service. Also the cloud solution works great if you don't want to deal with the scaling headaches.
|
|
#
?
Apr 28, 2016 03:26
|
|
|
OSI bean dip posted:We've been using it in a DFIR setting as of late God yes, Splunk is awesome for log comparison.
|
|
#
?
Apr 28, 2016 13:12
|
|
|
Check out FIDO from Netflix: https://github.com/Netflix/Fido A lot of Automation and Remediation built in to the tool. We rebuilt it into Splunk and its working great as a QRadar replacement. Here's the presentation we've been giving on it
|
|
#
?
Apr 28, 2016 13:53
|
|
|
|
| # ? May 10, 2024 17:40 |
|
|
Swagger Dagger posted:For the people asking about learning infosec, I think you could do a whole lot worse than reading through these: https://www.humblebundle.com/books/no-starch-hacking-books
|
|
#
?
Apr 28, 2016 14:35
|
|
