Pages: 1 [2] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 6 post(s) |
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2011.01.26 20:00:00 -
[31]
I would suggest don't turn off the non-ssl api servers, there's no need to encrypt public api calls like sovereignty, kills, alliances, etc.
I would rather change the access level. Like: - HTTPS: all calls - HTTP: allow only public and limited api keys (later only public calls)
That way the important full api key will be forced to use the ssl version and 90% of the apps will be still able to work if they haven't switched to ssl yet.
You can add a new error level that tells the developer/user they've to use the ssl api.
Sure I still see a security problem if people are using api via proxy (which is a matter of trust). But the final solution would only be to go away from the current api key system and switch to a oauth based system where YOU as USER can revoke every application that has access to your data (like twitter oauth or facebook applications).
|
Medarr
Amarr ZeroSec
|
Posted - 2011.01.26 20:13:00 -
[32]
Edited by: Medarr on 26/01/2011 20:15:15 I think you can generate your own certs and have to add an exception to the browser. Not sure if this is possible on an JesusPhone.
|
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2011.01.26 20:19:00 -
[33]
Originally by: Medarr Edited by: Medarr on 26/01/2011 20:15:15 I think you can generate your own certs and have to add an exception to the browser. Not sure if this is possible on an JesusPhone.
But sometimes you've no access to the certifcate store of your mobile phone or the computer. Then you've only the chance to use a trusted certificate.
|
Medarr
Amarr ZeroSec
|
Posted - 2011.01.26 20:21:00 -
[34]
Edited by: Medarr on 26/01/2011 20:22:29
Originally by: Wollari
Originally by: Medarr Edited by: Medarr on 26/01/2011 20:15:15 I think you can generate your own certs and have to add an exception to the browser. Not sure if this is possible on an JesusPhone.
But sometimes you've no access to the certifcate store of your mobile phone or the computer. Then you've only the chance to use a trusted certificate.
True but you can import/export them to a trusted device or computer.
ps, when i first saw your name i couldnt help but think.. Londo Mollari!!
|
Aineko Macx
|
Posted - 2011.01.26 20:44:00 -
[35]
With growing API functionality the granularity of limited and full key is too low IMO. The solution would be to allow custom configured keys, where users define which data items can get accessed by which key.
As for HTTPS, I highly approve of this. ________________________ CCP: Where fixing bugs is a luxury, not an obligation. |
Chainsaw Plankton
IDLE GUNS IDLE EMPIRE
|
Posted - 2011.01.26 21:27:00 -
[36]
Edited by: Chainsaw Plankton on 26/01/2011 21:27:27
Originally by: Aineko Macx With growing API functionality the granularity of limited and full key is too low IMO. The solution would be to allow custom configured keys, where users define which data items can get accessed by which key.
As for HTTPS, I highly approve of this.
I highly agree, a kill mail export key would be a nice start.
|
Zhalo Tyrik
|
Posted - 2011.01.26 21:51:00 -
[37]
Will you be adding api.eve-online.com to the SSL certificate so that it doesn't cause "bad domain" errors when using SSL? Or will you be forcing applications to use api.eveonline.com?
I bring this up since all the applications I've seen use the api.eve-online.com domain. Even the My Character page links to api.eve-online.com domain which of course returns an error since the domain is not included in the certificate. - |
mazzilliu
|
Posted - 2011.01.26 21:56:00 -
[38]
cool now go fix all the other api security issues
|
FullNelson Mandella
|
Posted - 2011.01.26 23:37:00 -
[39]
Originally by: Medarr Edited by: Medarr on 26/01/2011 20:22:29
Originally by: Wollari
Originally by: Medarr Edited by: Medarr on 26/01/2011 20:15:15 I think you can generate your own certs and have to add an exception to the browser. Not sure if this is possible on an JesusPhone.
But sometimes you've no access to the certifcate store of your mobile phone or the computer. Then you've only the chance to use a trusted certificate.
True but you can import/export them to a trusted device or computer.
ps, when i first saw your name i couldnt help but think.. Londo Mollari!!
Not all devices provide this functionality. A number of phones do not provide keystore management of any type. Some of these have the filesystem locked down so that export/import is impossible.
Think of other locked-down devices as well (web-enabled television tuners, xbox, playstation, etc.) that may have strange keystore management issues.
Building the trust into the application is a viable alternative, but a bit of a PITA.
|
Jacqueline Coeur
Gallente
|
Posted - 2011.01.26 23:55:00 -
[40]
Originally by: Trebor Daehdoow Now, I can certainly use https between the proxy and the Api server, but encrypting between the browser and the proxy will require buying a certificate, and I'm not sure I can justify the expense.
Considering that: 1) the grand total cost for an https certificate (without extended validation) is $0 2) even if you do not know where to get one, you can still use https with a certificate that is signed by your own root authority, as long as your users are willing to add your authority as a trusted root.
I do not see how https is a problem.
|
|
Nikolai Kondratiev
Sphere Design Inc.
|
Posted - 2011.01.27 00:22:00 -
[41]
Originally by: Trebor Daehdoow I appreciate (and largely agree with) the reasoning behind this, but it is probably going to kill my EViE skill training browser applet.
The reason for this is that javascript httpxmlrequest calls can only be made to the server that originated the enclosing page. So for EViE to work, I had to write a special proxy that bounces these requests off to the api server, and then returns the results (ie: Browser <-> Proxy <-> Api Server)
Now, I can certainly use https between the proxy and the Api server, but encrypting between the browser and the proxy will require buying a certificate, and I'm not sure I can justify the expense.
Well you don't HAVE to upgrade your website to SSL if it was fine without until now, whatever CCP makes the HTTPS mandatory for API calls or not.
Browser <--- HTTP ---> Your webserver <-- HTTPS ---> API Server _ Ore Table | PI Profits |
Catari Taga
Centre Of Attention Middle of Nowhere
|
Posted - 2011.01.27 01:26:00 -
[42]
Good change (if overdue), and working fine for TQ API, but for the SiSi API server it doesn't work (bad certificate followed by a 500 Internal Server Error response). --
|
Aineko Macx
|
Posted - 2011.01.27 09:12:00 -
[43]
Originally by: FullNelson Mandella The problem CCP will encounter is that they're probably going to acquire a Verisign cert signed by the G5 root CA, which is not in the Truststore of most phones over two years old.
For what its worth, CCP is using Entrust certs on Gate...
Originally by: Wollari But SSL is of course a real new world for most people and comes with new problems, like trusted certificate list, exact hostname matching, and ssl chains, etc (I know this from work).
Agreed. Working with related things for two years now. ________________________ CCP: Where fixing bugs is a luxury, not an obligation. |
Trebor Daehdoow
|
Posted - 2011.01.27 11:22:00 -
[44]
Edited by: Trebor Daehdoow on 27/01/2011 11:23:39
Originally by: Nikolai Kondratiev Well you don't HAVE to upgrade your website to SSL if it was fine without until now, whatever CCP makes the HTTPS mandatory for API calls or not.
Browser <--- HTTP ---> Your webserver <-- HTTPS ---> API Server
CCP clearly wants the data to be encrypted end-to-end. While I could do this (in fact, I have implemented it as a partial fix on my test server), I would very much want to fully honor the spirit and intent of the change.
I will implement this if I have absolutely no choice -- with appropriate warnings to the users of EViE -- but only as a last resort.
Originally by: Catari Taga Good change (if overdue), and working fine for TQ API, but for the SiSi API server it doesn't work (bad certificate followed by a 500 Internal Server Error response).
Make sure you're connecting to api.eveonline.com and not api.eve-online.com; the latter works but will generate a certificate error (or at least, it was yesterday).
Confessions of a Noob Starship Politician The most expensive free trip to Iceland you'll ever win!
|
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2011.01.27 13:16:00 -
[45]
Edited by: Wollari on 27/01/2011 13:24:40 Edited by: Wollari on 27/01/2011 13:16:56
Quote: If you're an API developer: You should update your application to access the API using HTTPS. The overhead of HTTPS is not that big, even on mobile devices. Due to this, we will turn off normal HTTP access to the API in the future. When a specific date is decided for when this to happen we will make sure to give you appropriate advance warning
No ... SSL doesn't have an impact on your application :-)
Querying 25k Corporations (loop with 25k corpIDs, one by one) with HTTP: 0:45 (h:mm) with HTTPS: 1:15
Average query time (25k Corporations) with HTTP: 0.9873s with HTTPS: 1.6796s
I don't wanna go multithreaded to start a DoS on your API servers. I hope that you can keep the non-ssl connection open for public APIs. Apart from that requests with multiple corporationID_s_ would be nice.
|
Catari Taga
Centre Of Attention Middle of Nowhere
|
Posted - 2011.01.27 13:19:00 -
[46]
Edited by: Catari Taga on 27/01/2011 13:20:05
Originally by: Trebor Daehdoow
Originally by: Catari Taga Good change (if overdue), and working fine for TQ API, but for the SiSi API server it doesn't work (bad certificate followed by a 500 Internal Server Error response).
Make sure you're connecting to api.eveonline.com and not api.eve-online.com; the latter works but will generate a certificate error (or at least, it was yesterday).
Thanks, but testapi.eveonline.com is the SiSi API server, and that's the one with the bad certificate (it has one for www.eveonline.com) and which produces a server error. --
|
|
CCP Stillman
|
Posted - 2011.01.27 13:40:00 -
[47]
Originally by: Wollari Edited by: Wollari on 27/01/2011 13:24:40 Edited by: Wollari on 27/01/2011 13:16:56
Quote: If you're an API developer: You should update your application to access the API using HTTPS. The overhead of HTTPS is not that big, even on mobile devices. Due to this, we will turn off normal HTTP access to the API in the future. When a specific date is decided for when this to happen we will make sure to give you appropriate advance warning
No ... SSL doesn't have an impact on your application :-)
Querying 25k Corporations (loop with 25k corpIDs, one by one) with HTTP: 0:45 (h:mm) with HTTPS: 1:15
Average query time (25k Corporations) with HTTP: 0.9873s with HTTPS: 1.6796s
I don't wanna go multithreaded to start a DoS on your API servers. I hope that you can keep the non-ssl connection open for public APIs. Apart from that requests with multiple corporationID_s_ would be nice.
If you're going to be doing large batches, you're obviously going to see a linear increase in time as a result of having to do a SSL handshake for each request.
It's advisable to limit SSL handshakes if you are going to do large queries like that. In those scenarios, there's nothing to stop you from creating a handful of persistent connections and pooling those for requests.
|
|
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2011.01.27 14:30:00 -
[48]
Edited by: Wollari on 27/01/2011 14:31:31 Edited by: Wollari on 27/01/2011 14:30:50
Originally by: CCP Stillman It's advisable to limit SSL handshakes if you are going to do large queries like that. In those scenarios, there's nothing to stop you from creating a handful of persistent connections and pooling those for requests.
I'll look into my api library if I can force php/curl to do some http keep alive. I think if I get the keep alive with php working the overall performance should be better since the connection hanshake would be obsolete ... But I still would like to perform batch queries :-)
|
Meeogi
Amarr
|
Posted - 2011.01.27 16:47:00 -
[49]
The day is coming where we play eve on the smart phones.
May god save us all
Wax on Wax off |
Ranka Mei
Caldari
|
Posted - 2011.01.27 19:49:00 -
[50]
Originally by: CCP Stillman No, EVEMon should still work correctly.
We're aware of another issue which causes the charactersheet to fail, which would affect EVEMon. We're fixing that as a part of Incursion 1.1.2, which is being deployed tomorrow.
<sarcasm>EVEMON? Yeah, I remember that.</sarcasm>
Seems they've given up on their end. :( Or slowed down development to 1/10th of the original. --
|
|
Series 1Alpha
Amarr
|
Posted - 2011.01.28 00:01:00 -
[51]
This is awesome. Can you please now have a look at this: EVE Docs which seems to have no documents listed or confirm if this is the full EVE API documentation.
|
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2011.01.28 09:26:00 -
[52]
Edited by: Wollari on 28/01/2011 09:35:38 Edited by: Wollari on 28/01/2011 09:29:59 php + curl + https + keepalive == really speedy.
23767 corporations sheets updated (including my database) in 22 minutes. (average request time 0.036s). that's even faster compared to single unencrypted api calls.
|
Vaerah Vahrokha
Minmatar Vahrokh Consulting
|
Posted - 2011.01.28 12:02:00 -
[53]
1) Please let the old API address work (maybe make it optional). There are way too many great applications that are not being updated since 1-2 patches ago and that will break, making my work impossible.
2) Don't you think the rush at securing the API with https is premature, when we have to give Full API keys to be accepted in some corps anyway? And an unknown guy can STILL read all our EvE mails?
3) Don't you think the rush at securing the API with https clashes with the utterly low privacy that by default plagues EvE Gate (everything given away by default both on Tranq (AND Sisi anyway))?
- Auditing & consulting
When looking for investors, please read http://tinyurl.com/n5ys4h + http://tinyurl.com/lrg4oz
|
Hud Bannon
|
Posted - 2011.01.29 01:38:00 -
[54]
Not a comp. sci. guru by any means, but what level encryption are we talking about? 128? I am not sure if HTTPS protocal can handle more than that but 128 is nothing to "crack" from what I understand. Again - just curious.
|
|
CCP Stillman
|
Posted - 2011.01.29 19:28:00 -
[55]
See PrismX's dev-blog for our plans when to stop supporting HTTP.
|
|
pushtaki
Gallente
|
Posted - 2011.02.01 11:23:00 -
[56]
so my capsuleer iphone app will stop working some day soon nullificationable |
Aineko Macx
|
Posted - 2011.02.05 20:38:00 -
[57]
Originally by: Hud Bannon Not a comp. sci. guru by any means, but what level encryption are we talking about? 128? I am not sure if HTTPS protocal can handle more than that but 128 is nothing to "crack" from what I understand. Again - just curious.
Looking at the certificate/https info of the API you'll see - symmetric key exchange using RSA asymmetric key encryption with 2048 bit modulus, certificate with SHA1/RSA signature, - actual data transport using 128 bit AES symmetric encryption That's your bread and butter https. ________________________ CCP: Where fixing bugs is a luxury, not an obligation. |
romex987
|
Posted - 2011.02.16 23:59:00 -
[58]
I am currently trying to learn to program just started.. :D using asp.net C#
I imported the libary list eveapi.live etc and am having trouble connecting i guess i will need to do more research now....
|
|
|
|
Pages: 1 [2] :: one page |
First page | Previous page | Next page | Last page |