New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Vultr and Cloudflare just sent me emails today about this as well
This depends on your configuration. But yes, CloudFlare itself can see all your traffic.
This is a terrible idea. Just use TLS client certificates and call it a day. Rolling your own crypto is almost guaranteed to end in a compromise due to some obscure detail you've missed, and this is a solved problem - the only thing that's lacking is the usability aspect.
Better advice: In case you are using SSL/TLS, just forget about CloudFlare
TLS performance is effectively a solved problem.
I'm just talking about CloudFlare. They don't have this data, and since the leaked data was mixed in with other random requests for other sites, a CloudFlare user has no way to determine impact, because the leak didn't happen in the requests they processed.
Sounds great - and is worthless and far off the problem field discussed. Which was "something better than changing ones password every 90 days". Encrypting or not, using tls or not was not at all even looked at.
Moreover just replacing passwords (or similar "I know" factors) simply is shifting the problem. Example: Rather than using 1 password for everything Joe and Jane Dumbuser will then use 1 key for everything.
Pardon me but the field of security is slightly more complex than "just use tls (and foss)".
See above. Although I agree that cloudflare is a lousy solution anyway.
You missed the point again. The problem isn't the symetric crypto part, which indeed is very fast and partly even supported in hardware. The problem is the startup part, PKE.
tls fans love to evangelize and like to focus only on the sym. part but an attack on a server won't attack sym. crypto - it will attack the startup, and that is vastly more expensive with tls. A server that could handle 10k connections/s without tls will typically handle just some hundred with tls.
You see, in ItSec we think in terms of attackability. For sym. crypto that simply the quality of the cipher and some side factors like, for instance, nonces, block modes, etc. tls, however, is usable as an attack vector simply by using it, because each and every new connection creates a quite considerable workload (besides the sad fact that tls, even 1.3 is rotten to the core but that should, of course, not disturb fans in their religious beliefs ...).
Security is a complex field and tls can be the answer sometimes (mostly due to gazillions of computers with ssl/tls infested software) but it also can become a security problem.
As for complexity of the field just have a look at the neighbouring Sha1 thread ... The news from these days ("Sha 1 is broken!!!1!") are next to irrelevant for many applications as collusion resistance simply isn't the problem with e.g. password hashes. Broken irreversibility on the other hand would be a show stopper.
Passwords being used plain stupidly, being weak, etc, is but one factor of many factors that are relevant. What I suggested brings two advantages: a) it allows Joe and Jane to have but one single password for everything yet de facto having site specific passwords and b) frequently changing ones.
Using that, btw, not only would be much better than what's used today (plain passwords over the wire) but it also would not need any encryption channel through which to be transported. Everyone could see it, no problem.
Going further one could even replace much of tls functionality because as soon as two parties have any shared secret they can do sym. crypto right away.
What it would, could, and doesn't deliver is server verification - but then PKI doesn't neither (it's utterly broken by design).
I feel DigitalOcean/CloudFlare are pushing the 'your data didn't show up in caches' point too hard - like, that's not the entire picture is it?
It's completely irrelevant, in fact. There are thousands of caches that CF has no access to nor will ever gain access to, and that they can't check. Data was exposed to everybody on the internet and anybody who happened to run a scraper will have gotten it, unknowingly.
CloudFlare is trying to downplay the issue, simple as that. Unfortunately, they seem to have sold the same BS to BitFinex as well.
You're missing the point. Password rotation isn't a desirable thing in the first place, and it seems like the real problem you're trying to solve is "reducing the impact of leaked credentials" - which is completely solved with keypair authentication, because the credentials are never sent anywhere.
For the same reason, "using 1 key for everything" is not a problem at all because the services never receive the key (unlike password authentication, where they do). The only scenario that leaves is "client system is compromised", in which case no amount of passwords or keys is going to save you.
So yes. Just use TLS client certificates (or equivalent keypair authentication schemes). They solve the problem effectively. Sure, there are more difficult problems in security, but this is not one of them.
All of this doesn't really matter when you consider that in a targeted attack, the thing that runs behind the connection is almost always easier to attack in terms of resource exhaustion.
(Also, you seem to be conflating security and availability.)
I refer you to this page.
Once again: keypair authentication is a much better solution for this than weird homebrew crypto schemes.
Aside from being pretty much irrelevant, this is true for many existing keypair authentication schemes as well.
Going further one could even replace much of tls functionality because as soon as two parties have any shared secret they can do sym. crypto right away.
Congratulations! You've reinvented half of TLS, except poorly.
Yes, PKI does. Not perfectly, not necessarily even well, but it does. I have repeatedly complained about this model being broken as well, but characterizing it as "not providing server verification" without qualifiers is simply wrong.
Well, what do midsize to large companies usually do when they are found fucking up?
The main culprit obviously is cloudflare whom, frankly, I perceive as a mere marketing "squeeze out whatever you can from that concept" organisation. By now, thanks in part to their own statement, we know that they are incompetent and, worse, probably don't care a rats ass about their customers. Classical case of "we must be good enough to not loose customers but win them. But being lousy and not getting caught is perfectly fine" from what I see.
And what should their customers like, for instance, DO do? Actually I think they can not even make a smart decision because for that they would need to know the real story which cloudflare certainly doesn't tell them.
So DO - and certainly others - grab the big straw that cloudflare put up in front and repeat the "oh it's just a in a gazillion" line.
Plus DO and the other customers have the excuse that they had a right to assume that cloudflare knows what it does and acts professional.
Funny that a not so big european provider, cociu, was the one with a good reaction, namely to shut off cloudflare for his business. And that's about the only reasonable reaction.
I don't see much wrong with DigitalOcean's post in that I'm not sure what else they could do at this point... but I am a bit disappointed in CloudFlare's. In the past they've been exceptionally transparent and that's one of the reasons I've always supported them. But if Google says CF is "severely downplaying the risk" I'm inclined to believe Google.
I get the reaction but I don't think it's necessarily a fair one. The suggestions given for how you should react are exactly appropriate. It doesn't much matter what did or didn't happen, what can be proved or what can't, people should be changing passwords and rotating out API keys. That should be the meat of any discussion on the topic at this point, from the perspective of moving forward with users.
It might be of mild comfort that you've not found your data in the wild, or that someone went hunting for it and also couldn't find it. I think it's fair to say that you looked and didn't find anything, so long as your suggestions for moving forward are very appropriate and not presented as "if you want to be extra careful" but rather "this is what you need to do now."
Nope. What you mean is "Password rotation isn't a desirable thing in the first place - seen from an ssl/tls fanatic believer".
Let me give you a tender hint: If someone breaks into a machine and gets root he will have your private keys - he will, however, not have your passwords.
That's a very very grave danger . Having the private keys of one side gives you the whole shebang.
Moreover a user has much tighter and better control over "I know" factors than over "I have" factors - and privkeys are a I have factor and usually one on machines with lousy to ridiculous security.
As I told you, ItSec is a little more complex than "tls solves all problems".
Now you might smartly tell me that the user secured his keys with a password. But then you would just have shifted the password problem plus it would be unrealistic (plus it could be cracked if an attacker has control over the machine)
Tell that to DDOS victims, some of whom have gone belly up.
Thanks for the laughing attack that gave me. Let me quote: "Hi, I am Valerie Anita Aurora (formerly Henson), a writer, programmer, and feminist activist." (programmer? let me guess. Js?)
But being at that, did you read it? It's about a collision attack. No hashed passwords cracked. So, what's fact? Google, i.e. a very major corp with very major computing resources, would, using very significant resources, succeed to find another password that had the same hash as mine. Wow.
So what? You seem to not know about password statistics (or, for that matter about ssl key statistics - you would be amazed if you did). The chance that on any server with more than a couple dozen users 2 or even more have the same password because humans love passwords like "secret123" is gazillion times higher than the risk you are concerned about.
And there we are not even comparing apples with apples because the google attack was on pure hashes while password databases use random salt for every password.
In other words: Even if google found another password with the same hash value they could not impersonate me (log in as me) as there is a salt.
You see, you are among the few here whom I usually take to be knowledgable but don't overdo it, ok. You picked the wrong guy for your zealotry attempts.
While you read aurora the feminists funny musing I actually design applications and libraries in that field and write code using H triples and loop invariants and have it statically verified and proven correct. And by "design" I mean something like TLA+ with full modelling and covering the full domain. Look it up, you might find it interesting.
As for tls, shift it up your arse that whole tls religion because if anyone gets a cert for some domain he plays "funny fred, the evil part" with all your users and their funny keys.
And btw. I know that "don't do homegrown crypto!" is one of the favourite "wisdoms" of those who feel that ItSec is a cool hobby but a) I did not say that I invented my own crypto, b) you have not even understood your own advice.
Which part of "I responded to 'use 90-day validity keys!'" did you fail to understand?
And do you really think that brillant people like Aumasson who worked i.a. on password hashing wrenches are stupid but you are the one Messiah who knows the truth? Gladly there are some real ItSec professionals out there while you preach the tls gospel ...
brazenness doesn't replace understanding and professionality. You'll learn that sometimes, probably with a bleeding snout.
Which part of "ASN is broken", "certificates are usually not even properly parsed", "whoever gets a certificate from whereever for a given server basically owns it and can divert, eavesdrop and manipulate traffic", "poison dns and get certs for those domains" etc, etc, etc did you fail to know about?
You lack the qualification for a professional discussion with me plus you behave like a respectless, arrogant asshole.
Go ahead and live happy with tls everywhere. I don't mind. I care about people who want to learn something and to be achieve more security, not about preachers of some religion.
They haven't been, though. They've just been very good at appearing transparent, by drowning readers in technical details. Pretty much every single one of their blog posts was written to conveniently detract attention away from how the sausage was made.
I don't know why you're trying to turn this into some kind of religious war. You seem to have an irrational hatred against TLS, without really fully understanding what it does or how it works.
False. If you have root, you can keylog. So yes, they will have your passwords.
No, they don't. Humans are terrible at remembering things, and therefore pick things that are easy to reproduce (which is precisely what you don't want in credentials).
You're presenting it here as if passwords and keypairs are of equal security and therefore passwords are better because people control them better. In reality, passwords are considerably worse, and your entire rationale falls apart.
Which I haven't disputed. Again, it seems like you're going for some kind of religious war here.
No, you haven't. You've added an additional layer. A very weak and questionable one for a non-transportable system, but an additional layer nevertheless.
I don't think you have even the slightest clue of how this kind of thing works. You don't just magically "crack" an encrypted private key. That's the whole point.
This has nothing to do with what I'm referring to.
Yes, I've read it. The reason I linked you to it, is because it illustrates how weakening of algorithms like this is often a warning sign that different weaknesses are going to be found in the near future with more serious impact. "It's not the exact kind of weakness that would compromise a password!" is practically irrelevant here.
What does any of this have to do with what I said?
Again, semi-religious rambling about TLS. Especially odd considering that the text you're quoting doesn't even mention TLS anywhere, and speaks of keypair authentication in general.
Sorry, but you're not making any points here - you're just trying to look impressive waving supposed "credentials" around, and making patronizing remarks. I don't care who you think you are, come up with an actual technical argument and we'll talk. Leave the dick measuring contest at the door.
More semi-religious anti-TLS rambling.
More patronizing remarks.
Did you miss the part where I said "Not perfectly, not necessarily even well"? I don't know what you think you're arguing against here.
And what qualification would that be, exactly?
Look in a mirror.
Fucking hell man, get your shit together. You're rambling like a madman barely making half a technical argument, inventing your own cryptographic schemes that completely miss the point, and making constant personal attacks.
Come up with actual technical arguments and I'll happily discuss them, but this kind of shitshow is really not worth any more of my time.
@joepie91
I stopped reading after a couple of sentences. Not deserving an answer, not even to be fully read.
We live in different strata. Let us just each one go their own way. I read Aumassons papers, you read auroras musings, and that's it. One doesn't need to know or to say more.
I get what you're saying, and you're right.
I guess I'm arguing more about practicalities. Apple provides no way for me to backup this data locally (which I don't really understand but...restoring from local backup did not fix it), and Google provides no way to back this up. So it's not just "something you have" but "something irreplaceable-without-massive-hassle you have" which is quite different.
The practical effect of having to use backup codes, etc. for dozens of sites renders Google Authenticator worthless for non-trivial use cases. For example, some people upgrade their phones every 2 years or even more frequently...I can't imagine going through that biannually. Much less piling hassle on top of a lost or broken or stolen phone. I think I do a good job of safeguarding my backup codes, but do most people? Etc.
We really need some meme art to go along with our new favorite phrase here on LET...
And it even matches the tls "solution" quite well!
PaintInTheMiddle attack.
For general amusement: A list of many cloudflare
victuhn, customershttps://github.com/pirate/sites-using-cloudflare/blob/master/README.md
Plus, as a bonus for those who were enchanted to read cloudflares nice blabla about "working closely with google" ... bing still has a lot in its caches, and so does yahoo. It seems reasonable that yandex, too, hasn't cleaned its caches (and probably is in no hurry)
cloudbleed. Cute.
Interesting theory, BUT I know from work that CF logs a LOT for various reasons (Debug, Legal, this, DR..), far more than you probably imagine (alone that infra fills a LOT of space in a US dc) - i pulled more than once month old data via support and the enterprise logging (accessible via SCP only) contains pretty much entire requests in and out. This was further extended after previous SSL (Heartbleed etc.) issues.
It is not a far fetched possibility that transactions - which would allow to see what data was sent including the memory dumped, not sure what your idea of a memory transaction log is, it obviously contains everything - are stored, for at least some time.
This is very cheap by now also, especially as - the irony - you can deduplicate these then if you throw some RAM at the storage servers (there is SW for this from eg. SAP, but as expected from SAP - $$$$$$... per CPU that is.)
CPU shadowing is not an issue anymore though dumping is hard (mostly by cache being too fast from what i understood - E7 Dual/Quad systems can do this somehow).
Same goes for SSL/TLS accelerator cards (and Xeon Phi modules) which generally offer low level dump options (eg. Intel), occasionally even public key signed (but this is again financial, and not for normal banks, you see these now after the Bangladeshi central bank "theft" revealed how insecure SWIFT is as backbone, that was comically easy).
TL;DR Anyway, not interested in defending CF but it's not true that there is "no way" they could have logged outgoing data (or have it), it is technically as well as financially very feasible to do so. For now as they seem to inform affected customers (which exist) there must be at least some logs, so i'll go with my theory for now.
The best part is that "change your X" solution that chuckleheads mocked for compromised emails is somehow the right thing to do for compromised passwords.
Compromised passwords is solved problem.
More better title to scare people here
Trying to drive traffic to your new forum?
I wonder how many will actually abandon Cloudflare's reverse proxy after this incident.
My bet is none.
There's https://cloudbleedcheck.com/ using that database too
I wonder how such logging level could be "Privacy shield" compliant.
(so: logs limited a) in time, b) in granularity and c) in scope; and possibly without "sensitive personal data")
Probably they would say they "never know if logging 100% of the TLS traffic leads to sensitive personal data processing in a specific transaction", which is a sort-of logical loop-hole to me
I feel like such a business, if head-quartered in Europe, would have to present a one thousand pages "privacy policy" document to its customers and probably would have to transparently certify how such "logs" are handled
A literal legal hell
I haven't read though all three pages yet but I'll respond to your comment anyway. If people really believed you could hide the IP by using CloudFlare...well, they've got to be pretty darn clueless.
It is very easy to obtain the IP of any domain hosted at CloudFlare.
Care to elaborate on this? I know some ideas but, please tell us more
we pass over that google made lots of us (if not all) sign in again by signing off our sessions a few days ago (was it yesterday?) android and drive client etc..
Anyone know anything?
generally it's easy to get the real ip of a domain proxified by CF, unless the domain has been put behind Cloudflare's DNS right after registration (or moved to the current server after DNS delegation to CF), never pointed to the real ip on a panel that wasn't Cloudflare's one and there has never been an MX or "direct-connect" DNS entry (or, those entries belong to a different machine). DROPping/REJECTing any non-CF connection directed to the listening port of your web server of choice would then be the complimentary. If the server doesn't offer fancy services and there's no gross misconfiguration along the way, it's fairly difficult to get the origin ip
all of this is greatly unnecessary but it seems that Cloudflare has been extremely successful in marketing a peculiar idea of perceived security
I mean it's incredibly more difficult for the average script kiddie to get an IP behind CloudFlare, as a general rule, than an IP directly behind the A record. Rarely is anything flawless.
I noticed that too. I just assumed it was related to this somehow.
Of course the sky is falling crowd are all waving their arms saying we should reset every password used everywhere ever even if it has nothing to do with Cloudflare because...reasons. Boogeymen under the bed and all that.
I wish people would take the time to understand stuff before giving such lazy advice or don't give any advice at all.