Connection to autotrade. is not encrypted

Is it correct, that collective2 provides no https?

So every time I poll the server my email address and password is transmitted unencrypted?

Collective2 does indeed provide https. Whether you use it is a software design decision you have to make. I would personally prefer that polling using session tokens be performed on unencrypted connections, but requesting sessions (and thus sending passwords) be done encrypted.

Thanks for your quick reply.

I get no response when I try to connect to the collective2 server per https.

I tried it also with firefox, but had not success.

http://autotrade … works but https doesn’t.

I confirm the problem. We’ll take a look and post a solution shortly.


Did this error occur just today, or is all the other software running without encryption? :slight_smile:

My second question. I need to subscribe to the C2 Test(Random) System. But as long as I get a email per trade I cannot subscribe…

So how could we solve this problem? Without the C2 Test System I cannot develop my software further.

Still not fixed…

Hi, Josef -

Upon review, we do not currently support https via the gen1 autotrade ports. We hope to add that capability in the future, but it is not something we can implement immediately.

Hi Matthew,

Is it correct that all the software vendors like




MB Trading

Genesis Securities

are forced to set up a unencrypted connection to initialize a session id.

And everytime the sessionid is renewed, my email address and password is sent to Collective2 unencrypted??

This is a huge security issue. I just want to remember on the stolen user data, bank account numbers, etc. at the end of the year 2009.

Please tell me that I’m totally wrong in my conception.

Hi, Josef:

Gen3 brokers use a different protocol than the Gen1 polling protocol. Gen3 communication is entirely encrypted.

I can confirm for you that currently Gen1 clients are using straight http and not using https. I agree with you that ideally we will want to migrate to using https. Your concern about security is certainly a valid one, but to put this into some perspective, it would require someone sniffing packets on the Internet and trying to intercept them. Further remember that brokerage passwords are never sent to C2 via the Gen1 protocol (that information resides solely on the user’s computer). Therefore, the main concern you have (and it is a valid one) involves the protection of C2 user credentials during the session token request.

Your message certainly does raise my awareness of this issue, and I appreciate that. For now, if you feel uncomfortable using the unencrypted session token request in the current Gen1 protocol, I would understand why you might want to delay.

Perhaps what we can do as an interim step is to make the session token request an entirely encrypted transaction through a separate secure port. That would serve to protect C2 user credentials, which I think is the main area of concern.

Let me see how quickly we can get this done. I’ll keep you posted on this forum. Thanks again for raising this issue.


We have implemented the security enhancements described in my previous post.

All developers using the C2 AutoTrade API (C2ATI) should check out the new docs available here:

I will summarize the two major changes below:

1) You can now use an encrypted connection to request a session token. Instead of calling…

you can now connect via the secure Web server like this:

In other words, cmd=autoTradeSessionReq can effectively replace cmd=login (note, however, that the former request goes through the standard Web server at the standard web port; it will redirect you to the proper IP and port upon successful login).

2) Also, regardless of whether you choose to use this new encrypted channel to request a session token, or whether you continue to request one directly via the autotrade server, you can now use the customer’s C2 Data Services password for authentication.

The C2 Data Services password does not grant full account access, but rather serves as a read-only password for certain automation features. Use of this password enhances customer security.

Learn more about the C2DS password here:

I believe these two enhancements will address many of your concerns.


Hi Matthew,

thanks for implementing the possibility for encryption.

Three things I wanted to add:

1) At is still just the old Documentation available.

2) Why is Password for C2 Data Services Access saved in plain text and not hashed?

What would be the fall-out for Collective2 to save the password hashed, too?

It is a good idea to have the C2DataService Password as login password for requesting a sessionid!

3) Two weeks ago was unreachable, because of a dns problem. So it wouldn’t have been possible to initialize a encrypted connection to C2. Would it make sense to implement a backup server?



  1. Sorry - we updated the docs but didn’t push it live. This is now fixed. Try refreshing the page when you call it in your browser:

    2) This is a good suggestion. We’ll see if it can be implemented in the short to medium term.

    3) Actually, we do already have two, redundant hosting facilities in operation, with backup hardware and software already in place. Unfortunately (as I already described in forum posts just after the incident) we had a database problem, and it corrupted the data at both facilities. We restored the data from an offline backup to solve the problem. This kind of incident will (I hope) be very rare. In the more typical scenario (a backhoe cuts through the fiber optic line going into our primary facility), we’ll be able to switch to the backup facility without too much hassle.