Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

When someone go to eBay's website, they use an unencrypted connection between their PC and eBay's server. If they sign in, they are redirected to a secure site identified by its certificate and may submit login credentials. After the user is logged in, they redirected again to the insecure connection.

I'm wondering... why does Ebay use this behavior? Why after the user is authenticated, how are they still using a secure connection between his PC and eBay server?

share|improve this question
What is your question? –  Adnan May 29 '13 at 10:26
They probably want to save money. This does leave the attack open to SSL stripping and cookie hijacking. Sadly, Ebay is not the only high profile site with poor security practices. LinkedIn also does something similar, and I believe Facebook's login page was in HTTP until fairly recently. –  Synderesis Jul 23 '13 at 18:47
add comment

2 Answers

up vote 3 down vote accepted

You might not have noticed this, but stackexchange works exactly the same. Authentication where the username and password are sent, is done through an https connection (so secured with SSL or TLS) after that the session id is sent plain over regular http, which could allow attackers to steal your session.

Now stackexchange works exactly the same and a lot of user asked the same thing, "Why are you doing this?" The explanation was that setting up SSL connections is very very CPU intensive, you might not notice this on your own webservers, but when you get thousands of requests a second, this can become problematic. Now there are solutions for this like SSL offloading, but they are quite expensive.

So my guess is that the reason ebay does this is very similar to the reason of why stackexchange does it: It costs money.

share|improve this answer
Also, there's a blog post by Adam Langley from Google. He says that moving GMail to HTTPS increased the CPU load by less than 1% and their network load by less than 2%. So if that's GMail, I don't really buy the "very very CPU intensive" claim. –  Adnan May 29 '13 at 10:58
In the case of stackexchange I could understand it. But we are talking about a big one as it is Ebay. I guess money shouldn't be a problem for Ebay, don't you think so? –  yzT May 29 '13 at 11:19
There's a great blog post by Nick Craver on the various challenges there are to making a site like StackExchange use site-wide SSL: nickcraver.com/blog/2013/04/23/… - a lot of this applies to sites like eBay too. –  Polynomial May 29 '13 at 11:50
Basically what Nick is saying is that also it takes effort and money, but they have not been able to do it because of meta subdomains. But once again, this isn't the case of Ebay. As @LucasKauffman says, this seems to be a business action, but I'd say it's a risky one. –  yzT May 29 '13 at 12:00
@TravisPessetto what has this to do with the question, also the symmetric key is not the same for all SSL sessions, it's randomly chosen every single time a session is set up. –  Lucas Kauffman May 29 '13 at 13:47
show 5 more comments

There is an oft-quoted result from Google stating that when they switched Gmail to site-wide SSL, they saw only a minor overhead which could be neglected. An important point, though, is that it is for Gmail which is not necessarily a typical Web application.

The CPU overhead for SSL is small. A basic PC CPU core can do AES encryption at more than 100 MB/s. The cryptography which happens during session establishment (the "handshake") can be done several hundred times per second with the same kind of core, and it does not occur often, thanks to both HTTP keep-alive and the SSL "abbreviated handshake". It makes sense that properly implemented SSL won't clog the server CPU for most kinds of Web sites.

Network overhead for a single connection is also slight. When in full swing, a SSL/TLS connection breaks data into individual records, with a header and some bytes for cryptographic support: 5 bytes for the header, 16 bytes for the per-record IV if using TLS 1.1+ and AES/CBC, 32 bytes for a SHA-256 HMAC, and 1 to 16 bytes of padding for alignment. At most 69 bytes. But the record can embed up to 16384 bytes worth of application data, so we are talking about a 0.4% extra bandwidth. Again, that's negligible.

However, there is a site-wide network overhead due to caching. When the same piece of data is to be downloaded by many distinct clients, it is worthwhile to uses caches, located between the main server and the clients: when one client connection, going through a cache, is for a file that the cache has, the cache can answer without having to disturb the main server. The client and server needs not be aware of that mechanism; that's called a transparent proxy. Many ISP run that kind of system.

Caches won't help much with Gmail, because each user has his own mailbox and there are few files which will be shared between distinct users. However, the situation with Ebay may be different, with all the item photos that they send, by definition, to a lot of clients. It is highly plausible that caching benefits much more Ebay's infrastructures than Gmail's. However, and that's the tricky point, SSL prevents most of this caching. By going site-wide SSL, Ebay could possibly incur a non-negligible impact, enough to give them reason to pause and think. I don't say that Ebay's not doing site-wide SSL is proven to be a question of cache-related performance, but at least it is a possible reason.

Of course, not doing SSL means that passive eavesdropping and active attacks are a possibility. From Ebay's point of view, there are trade-offs everywhere between security and usability. Ultimately, as @Lucas says, it is all about money.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.