Pages: 1 [2] 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
yumike
|
Posted - 2011.03.27 14:23:00 -
[31]
Originally by: Rakshasa Taisab
Originally by: yumike lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit.
Encryption, and even just plain old unencrypted connections, are handled by a front-end load-balancing server. So the 'lag' you're imagining is just in your head, as the sol node won't even know there's encryption involved.
Please learn stuff before posting.
Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data.
Pleasen learn stuff before posting.
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 14:25:00 -
[32]
Edited by: Miilla on 27/03/2011 14:30:06
Originally by: yumike
Originally by: Rakshasa Taisab
Originally by: yumike lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit.
Encryption, and even just plain old unencrypted connections, are handled by a front-end load-balancing server. So the 'lag' you're imagining is just in your head, as the sol node won't even know there's encryption involved.
Please learn stuff before posting.
Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data.
Pleasen learn stuff before posting.
Keep digging, soon you may strike oil.
SO, your entire argument is "wasting CPU cycles". I always wanted to meet somebody who knew it all. Your replying to my trolls is wasting CPU cycles, how about that? Not very efficient are you?
Now I have. *scratches that off 1001 things to do before I die*
|
Rakshasa Taisab
Caldari Sane Industries Inc. Initiative Mercenaries
|
Posted - 2011.03.27 14:38:00 -
[33]
Originally by: yumike Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data.
Pleasen learn stuff before posting.
Your post specifically mentions lag when 1k+ people gather in a system... And I am the one who's daft?
Also, I just said that the frontend servers would take care of the de/encryption load, not the sol nodes. So there's no 'destination server' who ends up 'wasting cpu time' as you claim, as the destination servers (sol nodes) are behind the frontend servers.
And the client has no problem doing decryption as the traffic is so low as to be insignificant in terms of CPU resource usage.
You don't know what you're talking about, so stop digging that hole.
|
yumike
|
Posted - 2011.03.27 14:39:00 -
[34]
Edited by: yumike on 27/03/2011 14:46:35
Quote: Keep digging, soon you may strike oil.
SO, your entire argument is "wasting CPU cycles". I always wanted to meet somebody who knew it all. Your replying to my trolls is wasting CPU cycles, how about that? Not very efficient are you?
Now I have. *scratches that off 1001 things to do before I die*
You had fun, I had fun. No waste in cycles at all ! nn
Quote: Your post specifically mentions lag when 1k+ people gather in a system... And I am the one who's daft?
Also, I just said that the frontend servers would take care of the de/encryption load, not the sol nodes. So there's no 'destination server' who ends up 'wasting cpu time' as you claim, as the destination servers (sol nodes) are behind the frontend servers.
And the client has no problem doing decryption as the traffic is so low as to be insignificant in terms of CPU resource usage.
You don't know what you're talking about, so stop digging that hole.
you very well could have a system like that in place, you'd have to add an extra value for your internal destination service and another method between zone nodes to do hand offs. i misunderstood you, i thought your reason for trying to load-balance was network throughput not cpu load bearing. also there would be no load-balancing that server since that'd fault so geo and rr are out. that would have to be a pretty beastly box to not only take the entire client base through it, but to be re-encrypting and doing states for all those clients.
but im sure you already thought of that right?
|
Awesome Possum
Original Sin. PURPLE HELMETED WARRIORS
|
Posted - 2011.03.27 14:39:00 -
[35]
Originally by: Miilla
Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s))
All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please.
Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams?
Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
I must've missed the devblog/fanfest panel letting us know this was happening. Link? ♥
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 14:41:00 -
[36]
Originally by: Awesome Possum
Originally by: Miilla
Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s))
All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please.
Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams?
Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
I must've missed the devblog/fanfest panel letting us know this was happening. Link?
Eve search may have it, it was posted on here from but removed by moderators as the fact they cannot prevent this as it is happening at the Virus scanner and you cannot block them easily without upsetting a LOT of customers.
It was on a leak from an Alliance forum, perhaps somebody has it here.
|
Jaldard
|
Posted - 2011.03.27 14:49:00 -
[37]
Originally by: Furb Killer Edited by: Furb Killer on 27/03/2011 13:43:41 Indeed, encryption is kinda useless if the client computer is 'compromised', then you can just read it directly from the memory. Not to mention since bots log for every neutral/red that jumps in that they put 330k char names in their virus definitions, risking pretty much every program randomly shuts down, when you can also read the screen way easier (yes i know miila is just a troll).
Encryption is used to make sure you cannot sniff the stuff via routers in the middle, packet sniffers that sniff wireless connections, etc. If your client is compromised you cannot hide your data, it needs to be unencrypted in the memory otherwise the user can never use it.
qft
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 14:52:00 -
[38]
Edited by: Miilla on 27/03/2011 14:53:48
Originally by: Jaldard
Originally by: Furb Killer Edited by: Furb Killer on 27/03/2011 13:43:41
Encryption is used to make sure you cannot sniff the stuff via routers in the middle, packet sniffers that sniff wireless connections, etc.
qft
He must have some secret way of sniffing his Browser SSL traffic that we don't know about..
|
King Aires
Privateers Privateer Alliance
|
Posted - 2011.03.27 15:05:00 -
[39]
Came here expecting Homage to the great show "Tales from the Crypt"
Left with a migrane
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 15:07:00 -
[40]
Originally by: King Aires Came here expecting Homage to the great show "Tales from the Crypt"
Left with a migrane
Take a chill pill.
|
|
Arnakoz
|
Posted - 2011.03.27 16:09:00 -
[41]
Edited by: Arnakoz on 27/03/2011 16:14:57 Edited by: Arnakoz on 27/03/2011 16:10:48 i'm not sure what the debate is here. if either the client or server is compromised then they have access to the SSL certs/keys, and can thus decrypt the info readily. period, end of story. the ONLY thing packet encryption is good against is sniffer between you and the server. like a guy in a hotspot/or tunneled into your network, running wireshark. he doesn't have access to the keys that would be used to decrypt the data. while its possible to eventually do so, it would take so long that it would be useless.
so the idea that it will stop bots from catching local info is just not plausible - b/c the bot would have access to the client and thus the keys. even if the keys were themselves encrypted they would be static on the client and thus (with some amount of time) be decrypt-able and then usable.
so, nuet/red somes into local - sends it encrypted data to the server, the server in turn sends encrypted data to your machine, at which point the bot would be just as capable as the client of decrypting.
even if it were possible to do as you're suggesting, bots can still use OCR and color recognition to see the non-blue in local on the screen. so you're talking more overhead for basically no purpose.
|
Dian'h Might
Minmatar Cash and Cargo Liberators Incorporated
|
Posted - 2011.03.27 16:22:00 -
[42]
Originally by: Miilla
Originally by: Awesome Possum
Originally by: Miilla
Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s))
All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please.
Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams?
Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
I must've missed the devblog/fanfest panel letting us know this was happening. Link?
Eve search may have it ... perhaps somebody has it
So what you're saying is that you have no documentation to backup your own claims, despite demanding such documentation from anyone who disagrees with you. - - - Dian'h Might - C&Ps resident "internet kleptomaniac" |
Julian Assagne
|
Posted - 2011.03.27 16:28:00 -
[43]
snooping as usual i see?
|
Asperath Fernandez
|
Posted - 2011.03.27 16:36:00 -
[44]
It totally works that way.
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
GGGAAAAAAAAAHHHHHHHHHHHHHHHHHH MY BROWSER NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
|
Lors Dornick
Caldari
|
Posted - 2011.03.27 17:11:00 -
[45]
1. Encrypting session traffic using for instance SSL isn't a big issue for the central servers since it could/would be handled by the load balancing proxies and could/would easily be offloaded to cryptographic accelerators. Just as it has for the last 10+ years in any server farm protected by SSL.
See Wikipedia for more info on that.
(As a side note, I've personally played with such hardware for at least 10 years, still have some early accel boards that I play with now and then).
2. Session encryption using for instance SSL wouldn't put any serious strain on client given that the amount of data transferred is very low compared to all other cpu intensive load that the client will have to deal with anyway.
3. Encrypting traffic to protect against sniffing on any of the end nodes is completely useless and actually silly if either part is compromised and/or and provides free access for the sniffer/analyser software since the private keys will be available to the sniffer/analyser.
4. As with most easy solutions, encrypting the client traffic would only work as a counter against very simple versions of a possible exploit. Any one who's invested time enough to create a nice working bot software wouldn't have to rely on such solution since it would be easy to integrate a sniffer into said software with minimal extra coding.
5. For anyone who's interested in the actual ramifications of the limitations of session encrypting I would recommend pondering the situations of most corporate/campus setups (and many home/small business ones). Where the network owner controls all routing and all nameservers and is able to direct any traffic anywhere and change any forward or reverse nameserver lookups. (How many of you have you own private key to verify the answer from your nameserver?).
// Lors |
Aeronwen Carys
|
Posted - 2011.03.27 20:11:00 -
[46]
Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping.
Please?
The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail.
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 20:12:00 -
[47]
Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47
Originally by: Aeronwen Carys
Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping.
Please?
The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail.
But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right?
|
Aeronwen Carys
|
Posted - 2011.03.27 20:16:00 -
[48]
Originally by: Miilla Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47
Originally by: Aeronwen Carys
Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping.
Please?
The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail.
But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right?
Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are.
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 20:19:00 -
[49]
Originally by: Aeronwen Carys
Originally by: Miilla Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47
Originally by: Aeronwen Carys
Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping.
Please?
The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail.
But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right?
Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are.
Keep raising the bar. Or should we just lay down and admit defeat like you?
|
Jenna Malone
Caldari W-hat LLC
|
Posted - 2011.03.27 20:21:00 -
[50]
Posting in a thread with an absolutely clueless OP. Would do again!!!!! A++++++++++
|
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 20:22:00 -
[51]
Originally by: Jenna Malone Posting in a thread with an absolutely clueless OP. Would do again!!!!! A++++++++++
So, how would you solve this problem then? Suggestions welcome.
|
Jenna Malone
Caldari W-hat LLC
|
Posted - 2011.03.27 20:25:00 -
[52]
Make this whole thread disappear as if it never happened.
The fanciest doorlocks are ****ing useless, if the thief comes in through the window. Which would be anything using Windows' debugger APIs, in this case.
|
Ivana Twinkle
GoonWaffe Goonswarm Federation
|
Posted - 2011.03.27 20:25:00 -
[53]
Originally by: Badger Molester
Originally by: Miilla Well, I didn't mean your asscup size did I.
n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro
not emptyquoting ******ed kid brother
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 20:26:00 -
[54]
Originally by: Jenna Malone Make this whole thread disappear as if it never happened.
The fanciest doorlocks are ****ing useless, if the thief comes in through the window. Which would be anything using Windows' debugger APIs, in this case.
Which are also detectable upon attaching to the process and will shut down the client and/or report the attempt.
|
Jenna Malone
Caldari W-hat LLC
|
Posted - 2011.03.27 20:28:00 -
[55]
Edited by: Jenna Malone on 27/03/2011 20:28:08 Because there aren't any kernel debugger interfaces, which an user space process would be none the wiser of, if it was running or not, are there?
How do you think crackers break copy protections? They use the same means as people who debug kernel and driver code.
|
Aeronwen Carys
|
Posted - 2011.03.27 20:29:00 -
[56]
Originally by: Miilla
Originally by: Aeronwen Carys
Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are.
Keep raising the bar. Or should we just lay down and admit defeat like you?
I do not believe at any point I suggested giving up. Merely that your "superb solution" is nothing more than uninformed idiocy, something at which you seem to excel.
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.03.27 20:29:00 -
[57]
Originally by: Jenna Malone Edited by: Jenna Malone on 27/03/2011 20:28:08 Because there aren't any kernel debugger interfaces, which an user space process would be none the wiser of, if it was running or not, are there?
How do you think crackers break copy protections? They use the same means as people who debug kernel and driver code.
Yes and most likely in the new security drive they will block eve from running if a debugger is running, also will **** off Eve API devs in the process.
|
Terminal Insanity
Minmatar Brutor Tribe
|
Posted - 2011.03.27 20:32:00 -
[58]
Originally by: Miilla Edited by: Miilla on 27/03/2011 13:28:38
Originally by: yumike
Originally by: Miilla
Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams?
Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.)
Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have.
You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying.
You dont understand what he's saying. SSL exists only to protect you from man-in-the-middle type attacks, or people who are sniffing data remotely. If the hacker has access to ether the server or client, he can see the encryption keys and use them to crack the ssl connection easily. Its not an exploit, its just a fact of how these things work.
If your local computer is compromised, no ammount of HTTPS/SSL/SSH is going to keep your private data safe. These methods only protect you against remote attackers.
|
Jenna Malone
Caldari W-hat LLC
|
Posted - 2011.03.27 20:32:00 -
[59]
Edited by: Jenna Malone on 27/03/2011 20:33:08 User space processes, like a goddamn game like EVE, will never know whether a kernel debugger or a hack using kernel debugging APIs is running. As such, the game can not kill itself, because it won't notice. Unless it starts scrubbing its memory values every time they're accessed, and like that's not computing and memory intensive.
And I don't see what EVE API devs have to do with it. They use web APIs.
Stop raising issues around topics you're ****ing clueless about.
|
me me2
|
Posted - 2011.03.27 20:34:00 -
[60]
Originally by: Terminal Insanity
Originally by: Miilla Edited by: Miilla on 27/03/2011 13:28:38
Originally by: yumike
Originally by: Miilla
Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams?
Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.)
Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have.
You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying.
You dont understand what he's saying. SSL exists only to protect you from man-in-the-middle type attacks, or people who are sniffing data remotely. If the hacker has access to ether the server or client, he can see the encryption keys and use them to crack the ssl connection easily. Its not an exploit, its just a fact of how these things work.
If your local computer is compromised, no ammount of HTTPS/SSL/SSH is going to keep your private data safe. These methods only protect you against remote attackers.
Remote being outside of either End boundaries in the End-to-End scenario, end to end being the application (client) and the destination (server).
|
|
|
|
|
Pages: 1 [2] 3 :: one page |
First page | Previous page | Next page | Last page |