It has been determined that a specially crafted TLS server can apparently make improperly sized Heartbleed requests to TLS clients, making requests for 64K of RAM from the client if it is using a vulnerable version of OpenSSL. Most commonly used web browsers should be immune (IE uses SChannel, Firefox and Chrome use NSS, Safari probably uses Secure Transport, and Opera uses Presto). However, there are a lot of other "browsers" (mostly custom solutions such as web scrapers) that are client-driven. Clients relying on OpenSSL in the system (sometimes transparently) are still vulnerable. It would be nice if you had a RESTful interface on a modified server that could confirm the Heartbleed status of a client if a quick script is written to point at the modified server. This feature would mostly be for businesses looking to further shore up defenses against Heartbleed as many have internal servers running cron jobs.
It has been determined that a specially crafted TLS server can apparently make improperly sized Heartbleed requests to TLS clients, making requests for 64K of RAM from the client if it is using a vulnerable version of OpenSSL. Most commonly used web browsers should be immune (IE uses SChannel, Firefox and Chrome use NSS, Safari probably uses Secure Transport, and Opera uses Presto). However, there are a lot of other "browsers" (mostly custom solutions such as web scrapers) that are client-driven. Clients relying on OpenSSL in the system (sometimes transparently) are still vulnerable. It would be nice if you had a RESTful interface on a modified server that could confirm the Heartbleed status of a client if a quick script is written to point at the modified server. This feature would mostly be for businesses looking to further shore up defenses against Heartbleed as many have internal servers running cron jobs.