Hermmmm... this "shared secret key", which have been established during the session negociation, is, by definition, secret, and only known by the two connected machines... So, how could an attacker inject data which makes sense in the stream (as data is interpreted as encrypted by the secret key), or decrypt anything exchanged (as data is, indeed, encrypted by the session key)?
Just because the encryption uses a symetric algorithm during the connection, and no more an asymetric one like the one used in session negociation, does not make it more insecure!
This is still more complex than that... There is no fixed number "n" indicationg the number of packets to be sent without being acknowledged.
During the three-way handshake, the client and the server (read: the machine which actively opens the connection, and the machine which agrees to this connection) both advertize the number of data they can immediately recieve, which is called the "window". A machine is allowed to send as many bytes of data as the window is tall, without waiting for an ACK.
When an ACK is recieved by the sender, this means that the reciever acknowledged having successfully recieved all bytes, up to the one whose seq. number is the ACK number. The number of bytes ACKed will be suppressed from the sender's retransmission queue.
The reciever, sending an ACK, will in the same packet advertise a new window to the sender, for more data to be sent.
If data is not acknowledged into a given amount of time, the data still unacknowledged (on the retransmission queue), will be re-sent.
Sure, they could just encrypt everything, but then the code would be inscrutable
No.
Client-side security has always be totally pointless; if your CPU can execute the binary code, THEN you can dis-assemble it, scrutinize it, and modify its data flow as you like. If the code is encrypted, your CPU will have first to decrypt it, which means that you have the key to somewhere (well, maybe buried in a binary, but the plain key is always findable). The only way for them to ensure there is some security, is to make all data blocks redundant, and make them processed by random machines....
However, I think the data crunching code should be executed in a kind of sandbox (a la Java), preventing it from having access to the system... This would allow users to safely execute un-verfied (or badly-verified) code in their machines...
Re:*SAFE* refresh... Is slashdot broken?
on
Web Site "Lock-In"
·
· Score: 1
Is it just me, or were the and tags of this post actually rendered as real HTML tags instead of being quoted by the Slashdot engine? Those are supposed to be forbidden in HTML formatted posts... But by browser executed the Javascript within the previous post, and I can view the un-quoted tags in the source Well... strange
> No web - no Slashdot (no websites at all), no Linux (most of the collaboration that made Linux possible was done over the net)
OK for slahsdot - well, a website without web would be quite irrelevant, wouldn't it? - but you seem to imply the web is the only thing that ever existed on the net... ftp, gopher, archie and others allowed file/data/information sharing long before the web ever existed. Sure, the web can be considered a "better" medium, and sure, hypertext has enourmous advantages, but ftp is still widely used to exchange Open Source/GPLed programs, for example. Open source would have existed without web; indeed, it existed before the web existed.
Well, it has not yet be proven thet Elvis was seen in a UFO, although it seems there has been some proof someone actually won the British national lottery...
Is there really no mean to shut this guy down? Trolls can be funny sometimes, but this guy is starting to be really annoying... Shouldn't posts be marked as SPAM, a definitely deleted from the server?
> I'm not sure here (perhaps someone could help me out here), but i think solaris is considered to be pretty damn secure.
Well, if you browse Solaris' known security vulnerabilities on (for example) securityfocus, you will see there are plenty of them. You can find 3 times as much known holes in Solaris 7 (2.7 renumbered) as, for example, in Linux Redhat 6.1 - not to mention Debian Potato. Not that this is a good way to evaluate a system's level of security, though, but that shows that assertions about Solaris being a "pretty damn secure" OS should be taken with a pich of salt... And, yeah, despite Sunsolve, our Solaris servers were cracked a few times, using buffer overflows problems (rpc.ttserverdb) or bad security checks (ff.core) from the system.
Slashdot Mirror
I meant Instruction Pointer, too...
And IP == Internet Protocol, Interrupt Process, Internet Protocol, Intellectual Property ...
I use Debian for the firewalling
Debian for the servers
and Debian for the desktop
But I'm not dedicated to a particular distribution... or am I?
Hermmmm... this "shared secret key", which have been established during the session negociation, is, by definition, secret, and only known by the two connected machines... So, how could an attacker inject data which makes sense in the stream (as data is interpreted as encrypted by the secret key), or decrypt anything exchanged (as data is, indeed, encrypted by the session key)?
Just because the encryption uses a symetric algorithm during the connection, and no more an asymetric one like the one used in session negociation, does not make it more insecure!
This is still more complex than that... There is no fixed number "n" indicationg the number of packets to be sent without being acknowledged.
During the three-way handshake, the client and the server (read: the machine which actively opens the connection, and the machine which agrees to this connection) both advertize the number of data they can immediately recieve, which is called the "window". A machine is allowed to send as many bytes of data as the window is tall, without waiting for an ACK.
When an ACK is recieved by the sender, this means that the reciever acknowledged having successfully recieved all bytes, up to the one whose seq. number is the ACK number. The number of bytes ACKed will be suppressed from the sender's retransmission queue.
The reciever, sending an ACK, will in the same packet advertise a new window to the sender, for more data to be sent.
If data is not acknowledged into a given amount of time, the data still unacknowledged (on the retransmission queue), will be re-sent.
Well, hope it helps...
No.
Client-side security has always be totally pointless; if your CPU can execute the binary code, THEN you can dis-assemble it, scrutinize it, and modify its data flow as you like. If the code is encrypted, your CPU will have first to decrypt it, which means that you have the key to somewhere (well, maybe buried in a binary, but the plain key is always findable). The only way for them to ensure there is some security, is to make all data blocks redundant, and make them processed by random machines....
However, I think the data crunching code should be executed in a kind of sandbox (a la Java), preventing it from having access to the system... This would allow users to safely execute un-verfied (or badly-verified) code in their machines...
Is it just me, or were the and tags of this post actually rendered as real HTML tags instead of being quoted by the Slashdot engine? Those are supposed to be forbidden in HTML formatted posts... But by browser executed the Javascript within the previous post, and I can view the un-quoted tags in the source
Well... strange
Well, it's
GET / HTTP/1.0\n\n
indeed... The HTTP 1.1 protocol wants a Host: header, as it is said in another post.
But you also can do:
nc proxy.whatever.com 8080
GET http://www.slashdot.org/ HTTP/1.0
> No web - no Slashdot (no websites at all), no Linux (most of the collaboration that made Linux possible was done over the net)
OK for slahsdot - well, a website without web would be quite irrelevant, wouldn't it? - but you seem to imply the web is the only thing that ever existed on the net... ftp, gopher, archie and others allowed file/data/information sharing long before the web ever existed. Sure, the web can be considered a "better" medium, and sure, hypertext has enourmous advantages, but ftp is still widely used to exchange Open Source/GPLed programs, for example. Open source would have existed without web; indeed, it existed before the web existed.
Cheers
GruikMan
Well, it has not yet be proven thet Elvis was seen in a UFO, although it seems there has been some proof someone actually won the British national lottery...
Is there really no mean to shut this guy down? Trolls can be funny sometimes, but this guy is starting to be really annoying... Shouldn't posts be marked as SPAM, a definitely deleted from the server?
> I'm not sure here (perhaps someone could help me out here), but i think solaris is considered to be pretty damn secure.
Well, if you browse Solaris' known security vulnerabilities on (for example) securityfocus, you will see there are plenty of them. You can find 3 times as much known holes in Solaris 7 (2.7 renumbered) as, for example, in Linux Redhat 6.1 - not to mention Debian Potato. Not that this is a good way to evaluate a system's level of security, though, but that shows that assertions about Solaris being a "pretty damn secure" OS should be taken with a pich of salt...
And, yeah, despite Sunsolve, our Solaris servers were cracked a few times, using buffer overflows problems (rpc.ttserverdb) or bad security checks (ff.core) from the system.
anyway, the above post was clearly a troll.