Yeah fair enough, my point wasn't particular about taxes, tho.
It was about the crazy emphasis the U.S.A. puts on military spending and how much corporate welfare is going on courtesy of Mr Taxpayer - all at the same time we hear "U.S.A. No 1 - U.S.A. No 1" and it starts to get old real quick.
In fact I'm an idiot for biting the troll hand but I guess I snapped this one time.
But seriously, if you think that was thought up ahead of time, and I'd been waiting to use... don;t you think it'd be a little more polished?
I don't - the best crap is the crap spewed forth like milk through the nostrils when you discover your girlfriend has been jerking off your dog into the orange juice.
* True polymorphism for generic types (look to ML) * Real templates (a la C++) with anonymous strict typed compiled instances * Better interaction with native C libraries - JNI stinks - look how perl processes headers, maybe do something like this * Only one superclass - bah, that is a pain * Annotations - whose idea was this crap? Make it a real part of the language so it can be enforced
Don't get me wrong, I make my bread and butter from Java, but lets not kid ourselves that it has issues.
Re:This is news for nerds?
on
Loebner Talks AI
·
· Score: 2, Funny
I do, it's just that SSL covers both. The difference is that the "where" in this case is not an IP address, but a private key, which is considerably more secure.
As I mentioned before adding security to the location increases the difficulty in pulling off a hack / redirect. I think that using SSL for location security is the wrong approach (application layer) - it should be at the network layer.
So, in other words, anywhere between here and the root servers, someone could pull an effective MITM.
No, since each recursive lookup also involves pulling down a signed record indicating where the next level of lookup should go. That next level pull is for the next level key, signed/hashed using the root level key ad infinitum.
Say I'm looking for www.blah.com (grossly simplified, but gets the idea across)
Now I will have root (level 0) key locally, so my machine goes to level 0 server, asks for where the server for level 1 of blah.com is and gets a signed hash of level 1 key.
It replies with where level 1 server for blah lives signed using level 0 key.
Now I contact level 1 server and ask it for its key info for blah.com.
It replies with the level 1 key that can be used to verify responses from the level 1 server, and I check the hash matches that retrieved in first contact.
Now I ask level 1 server for where www.blah.com can be found, it replies with the IP address signed using its key from level 1.
The chain of trust above is the hierarchical nature of the key signing (search for "secured pointers" and or/DS DNS record), or look here
From a technical standpoint, there is no man in the middle - you must do something equivalent to certificate forging/stealing or some kind of social engineering hack.
I know this isnt a "spam" killer, its one of the tools we will need to begin to fight back. Verifiable sources are vital.
So since you went to the effort of filling the form in, here we go:
* technical approach
As I mentioned, I was not advocating it as being _the_ solution, just one of the tools that will come in handy for various reasons
* It will stop spam for two weeks / open relays in foreign countries / armies of worm riddled broadband windows boxes
Of course all of these things will not go away just from securing domain name lookups - things get a lot easier to check when we "know" the source of the connection. It helps in tracking down where the spam is coming from - the "stopping it" bit has to follow the existing model (police action / court etc), until a more workable situation can be found. But to look at the situation with telephones, caller ID makes a huge difference to tracking down criminals.
* Countermeasures must work if phased in gradually
Lets imagine we have location security, we can begin to build a web of trust for mail servers now. DNSSEC is a pre-requisite to beginning to clean up the dirty parts of the web.
* Ideas similar to yours are easy to come up with, yet none have ever been shown practical / Feel-good measures do nothing to solve the problem
Fair enough, I've tried to show you it does have some benefits, and I will leave it at that.
(1) DNSSEC is signed DNS entries, where the fetch of each domain level retrieves a key and DNS entries signed using a private copy of that key. Client verifies entries using the public copy of the key.
There is no idea of a certificate authority as yet, the "trust" comes down the tree from the root DNS servers.
(2) You still don't seem to see the difference between securing the stream, and securing information about where the stream should be sent to.
(3) No need for rudeness. I'd suggest you read up some more on security.
It does, however, have to be the private key of either the real owner or someone at a CA.
What does DNSSEC provide, exactly? I don't see any kind of CA system in place.
Lets imagine that via social engineering I am able to get a fake certificate signed, so its trusted. Without DNSSEC I can spoof the DNS and off we go with my dodgy parallel site.
With DNSSEC, I have to go to the additional effort of social engineering the DNS entry too - its far from perfect, but as I mentioned before, its an additional bit of confidence or barrier to pulling off some kind of site re-direct
How so, if you're already using SSL?
It's like encrypting a file with single DES, and then re-encrypting that same file with AES256. WTF was the point of the DES in the first place?
Not really, its not a second level of the same thing, its securing something different to SSL - the server location / discovery.
And let's not forget how many browsers don't support DNSSEC, or how many people will just use a public terminal.
If we're going to make things secure, it has to go both ways -- users have to be educated, at least somewhat ("Look for the green bar!"). If we're not going to be secure (just call a number you found on an untrusted link to your bank site, and give them all your info), what's the point of this discussion?
First thing - DNSSEC wont be just a browser thing - should be supported at the OS level really. But regarding naive users - I totally agree with you - its impossible to do any of this without education on the part of users - but we should at least attempt to provide some level of trust for server locations too. I know your question was originally relating to HTTPS, but the internet is not just secure websites - what about securing email? As I mentioned before, I'd love this since we can then begin to clear up the mess that is spam.
You are absolutely correct - for spoofing with HTTPS to work without provoking some kind of warning, the spoofer needs a "valid" certificate (private key) with a valid correct certificate chain for the domain in question - it doesn't have to be the private key of the real owner... Social engineering for getting such a thing is feasible.
DNSSEC like HTTPS and certificates are all armour against malicious attackers, but as any security guy will tell you, there is no such thing as 100% real security, just various levels of confidence. DNSSEC helps in adding some extra confidence.
But lets not forget how many people just use unsecured site access - I pop along to my bank http site to obtain a phone number to call them....
DNSSEC is actually buying the initial phone number (ip address) lookup security. Current DNS is unsecured - if I spot an unsecured phone number lookup go past on the 'net, I can spoof back my phone number - and from there on in even if you use HTTPS you are talking to the wrong person....
In fact, DNS sec is one of the things I'd really like to see widespread adoption of, with it we can actually start to make some headway in turning off the spam (we can reverse lookup who is trying to send the mail, and be *"faily sure" that it is coming from someone we allow to send us mail.
* For interesting values of "faily sure", since of course even DNSSEC relys on a tree of trust, much like SSL certificates.
Slashdot Mirror
Ha ha ha ha ha ha. Nice one. I'm a print it out and use it as toilet paper. Thanks.
Yeah fair enough, my point wasn't particular about taxes, tho.
It was about the crazy emphasis the U.S.A. puts on military spending and how much corporate welfare is going on courtesy of Mr Taxpayer - all at the same time we hear "U.S.A. No 1 - U.S.A. No 1" and it starts to get old real quick.
In fact I'm an idiot for biting the troll hand but I guess I snapped this one time.
Ah, what amazing bravado Mr Internet has.
Now go back to paying your taxes for all your military and big business handouts.
Sometimes you just need to rub a dog's nose in its own shit and get it over with.
And sometimes the dog won't notice how disgusting its own shit is, and you have to resort to pushing the poo physically back up the dogs arse.
Unfortunately this is far more commitment than I'm willing to give.
But seriously, if you think that was thought up ahead of time, and I'd been waiting to use... don;t you think it'd be a little more polished?
I don't - the best crap is the crap spewed forth like milk through the nostrils when you discover your girlfriend has been jerking off your dog into the orange juice.
Parent poster admits to using iTanic - someone tie his hands to the tree while I call the Vet.
We will tranq him and put him in a zoo. This will mean big things for us, big things. Tours on broadway, my picture on the cover of Time....
I seriously doubt it shuts down every two hours. No Windows system is stable that long at a time.
To be fair they achieve this guiness book of records feat by forcing the machine into sleep state C1 for the last 1 hour thirty minutes.
Hmm on my planet the females must bare their breasts immediately when asked by I.T. professionals.
It does not seem to be the case here on this planet. I shall continue investigating after I have been "Booked" I believe is the term.
Hitler made Mussolini run on thyme?
What a mad parallel universe this is. I shall now experience some of your earth "sex".
Did you ever stop to think that maybe the original poster isn't from an English speaking country (e.g. America).
But Father, I just want to - SING!
Well lets say the system is automagically under the hood tracking changes and saving versions.
The user gets to a "happy place" in the document, clicks 'Label This Version' and types in 'ready for accountant'.
The system creates a version of the object in question and labels it (a-la CVS tagging).
Further forward in the future, disaster happens, users sighs, clicks 'Revert to an earlier version' and selects the 'ready for accountant' version.
Document reverts back.
I've read a lot of your replies on this subject here, and don't understand your hostility to versioning?
Versioning with user friendly labels is about as easy as it is possible to make it.
All of your above problems are easily resolved by allowing the user the ability to version the objects in question.
The history of versions then provides the necessary mechanic for walking the modifications tree.
Versioned object databases have been doing this for years.
Why is the title of this red on the front page???
It's red rag day. The painters are in. Time of the month. Shes got teh mormons in.
Or something.
Some pet hates about Java:
* True polymorphism for generic types (look to ML)
* Real templates (a la C++) with anonymous strict typed compiled instances
* Better interaction with native C libraries - JNI stinks - look how perl processes headers, maybe do something like this
* Only one superclass - bah, that is a pain
* Annotations - whose idea was this crap? Make it a real part of the language so it can be enforced
Don't get me wrong, I make my bread and butter from Java, but lets not kid ourselves that it has issues.
I'm just here for the comments!
I'm not even here!
Yep the spam form was what I was getting at.
I do, it's just that SSL covers both. The difference is that the "where" in this case is not an IP address, but a private key, which is considerably more secure.
As I mentioned before adding security to the location increases the difficulty in pulling off a hack / redirect. I think that using SSL for location security is the wrong approach (application layer) - it should be at the network layer.
So, in other words, anywhere between here and the root servers, someone could pull an effective MITM.
No, since each recursive lookup also involves pulling down a signed record indicating where the next level of lookup should go. That next level pull is for the next level key, signed/hashed using the root level key ad infinitum.
Say I'm looking for www.blah.com (grossly simplified, but gets the idea across)
Now I will have root (level 0) key locally, so my machine goes to level 0 server, asks for where the server for level 1 of blah.com is and gets a signed hash of level 1 key.
It replies with where level 1 server for blah lives signed using level 0 key.
Now I contact level 1 server and ask it for its key info for blah.com.
It replies with the level 1 key that can be used to verify responses from the level 1 server, and I check the hash matches that retrieved in first contact.
Now I ask level 1 server for where www.blah.com can be found, it replies with the IP address signed using its key from level 1.
The chain of trust above is the hierarchical nature of the key signing (search for "secured pointers" and or/DS DNS record), or look here
From a technical standpoint, there is no man in the middle - you must do something equivalent to certificate forging/stealing or some kind of social engineering hack.
I know this isnt a "spam" killer, its one of the tools we will need to begin to fight back. Verifiable sources are vital.
So since you went to the effort of filling the form in, here we go:
* technical approach
As I mentioned, I was not advocating it as being _the_ solution, just one of the tools that will come in handy for various reasons
* It will stop spam for two weeks / open relays in foreign countries / armies of worm riddled broadband windows boxes
Of course all of these things will not go away just from securing domain name lookups - things get a lot easier to check when we "know" the source of the connection. It helps in tracking down where the spam is coming from - the "stopping it" bit has to follow the existing model (police action / court etc), until a more workable situation can be found. But to look at the situation with telephones, caller ID makes a huge difference to tracking down criminals.
* Countermeasures must work if phased in gradually
Lets imagine we have location security, we can begin to build a web of trust for mail servers now. DNSSEC is a pre-requisite to beginning to clean up the dirty parts of the web.
* Ideas similar to yours are easy to come up with, yet none have ever been shown practical / Feel-good measures do nothing to solve the problem
Fair enough, I've tried to show you it does have some benefits, and I will leave it at that.
Have a good day.
Mr Thinly Sliced.
(1) DNSSEC is signed DNS entries, where the fetch of each domain level retrieves a key and DNS entries signed using a private copy of that key. Client verifies entries using the public copy of the key.
There is no idea of a certificate authority as yet, the "trust" comes down the tree from the root DNS servers.
(2) You still don't seem to see the difference between securing the stream, and securing information about where the stream should be sent to.
(3) No need for rudeness. I'd suggest you read up some more on security.
It does, however, have to be the private key of either the real owner or someone at a CA.
What does DNSSEC provide, exactly? I don't see any kind of CA system in place.
Lets imagine that via social engineering I am able to get a fake certificate signed, so its trusted. Without DNSSEC I can spoof the DNS and off we go with my dodgy parallel site.
With DNSSEC, I have to go to the additional effort of social engineering the DNS entry too - its far from perfect, but as I mentioned before, its an additional bit of confidence or barrier to pulling off some kind of site re-direct
How so, if you're already using SSL?
It's like encrypting a file with single DES, and then re-encrypting that same file with AES256. WTF was the point of the DES in the first place?
Not really, its not a second level of the same thing, its securing something different to SSL - the server location / discovery.
And let's not forget how many browsers don't support DNSSEC, or how many people will just use a public terminal.
If we're going to make things secure, it has to go both ways -- users have to be educated, at least somewhat ("Look for the green bar!"). If we're not going to be secure (just call a number you found on an untrusted link to your bank site, and give them all your info), what's the point of this discussion?
First thing - DNSSEC wont be just a browser thing - should be supported at the OS level really. But regarding naive users - I totally agree with you - its impossible to do any of this without education on the part of users - but we should at least attempt to provide some level of trust for server locations too. I know your question was originally relating to HTTPS, but the internet is not just secure websites - what about securing email? As I mentioned before, I'd love this since we can then begin to clear up the mess that is spam.
You are absolutely correct - for spoofing with HTTPS to work without provoking some kind of warning, the spoofer needs a "valid" certificate (private key) with a valid correct certificate chain for the domain in question - it doesn't have to be the private key of the real owner... Social engineering for getting such a thing is feasible.
DNSSEC like HTTPS and certificates are all armour against malicious attackers, but as any security guy will tell you, there is no such thing as 100% real security, just various levels of confidence. DNSSEC helps in adding some extra confidence.
But lets not forget how many people just use unsecured site access - I pop along to my bank http site to obtain a phone number to call them....
DNSSEC is actually buying the initial phone number (ip address) lookup security. Current DNS is unsecured - if I spot an unsecured phone number lookup go past on the 'net, I can spoof back my phone number - and from there on in even if you use HTTPS you are talking to the wrong person....
In fact, DNS sec is one of the things I'd really like to see widespread adoption of, with it we can actually start to make some headway in turning off the spam (we can reverse lookup who is trying to send the mail, and be *"faily sure" that it is coming from someone we allow to send us mail.
* For interesting values of "faily sure", since of course even DNSSEC relys on a tree of trust, much like SSL certificates.
Mr Thinly Sliced
Five digits - ha ha ha ha ha ha. My opinion - keep the mails coming please!
For some bizarre reason I typed in "cock ness monster" due to your mention of a penis and was suitably shamed by the results.
Yep, belgium here too, no youtube - whois shows dodgy IPs:
YOUTUBE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
YOUTUBE.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
YOUTUBE.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM
YOUTUBE.COM
And here is some non-caps text to stop slashdot bitching about me yelling. Bah.
Interesting. Wonder if its the original author posting twice, or a drive by posting.