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?

  • What is your question?
    – Adi
    Commented May 29, 2013 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
    Commented Jul 23, 2013 at 18:47
  • The question title is "how", the question is "why". The accepted answer is about the why, not the how. Why don't you ask how this is still secure?
    – SPRBRN
    Commented Apr 23, 2014 at 9:41

2 Answers 2


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.

  • 10
    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.
    – Adi
    Commented May 29, 2013 at 10:58
  • 3
    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
    Commented May 29, 2013 at 11:50
  • 3
    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.
    – user15194
    Commented May 29, 2013 at 12:00
  • 3
    @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. Commented May 29, 2013 at 13:47
  • 2
    @TravisPessetto it has nothing to do with that actually, it would still take trillions of years to break the symmetric key even if you have managed to pass a 1.000 messages on one symmetric key. Commented May 29, 2013 at 14:01

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.

  • 1
    This answers "why" HTTP is preferred by Ebay, but not "how" this login method is still secure when starting with HTTP.
    – SPRBRN
    Commented Apr 23, 2014 at 9:44
  • 1
    Well, technically, the non-SSL HTTP is not secure -- it is vulnerable to MitM attacks. I am just explaining the reasons why Ebay may tolerate this vulnerability. Commented Apr 23, 2014 at 10:40
  • I suppose they send the login (username plus password) over HTTP and then redirect to HTTPS and setup the session or something, but I don't see how this can be secure at all. What does HTTPS offer here except some false sense of security?
    – SPRBRN
    Commented Apr 23, 2014 at 12:20
  • The HTTPS will at least ensure that the password does not travel "as is" over the Internet. This is in no way "complete" as far as security is concerned, but allowing a password to travel unprotected would look really bad. Remember that Ebay's business, ultimately, is not about protecting the user; it is more about protecting Ebay. Commented Apr 23, 2014 at 12:24
  • @ThomasPornin, "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." At least one CDN seems to have solved the latter problem, which would seem to imply eBay is, today, even less justified in using plain HTTP than it might have been a couple of years ago. Or is my understanding incorrect? Commented Jan 20, 2016 at 0:00

You must log in to answer this question.