Skip to main content
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
Source Link

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

  • Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.

  • If you are unsure, ask the person/company that wrote the application.

  • If you are a developer, find out what library your app is using for TLS connections and testtest to be certain.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

  • Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.

  • If you are unsure, ask the person/company that wrote the application.

  • If you are a developer, find out what library your app is using for TLS connections and test to be certain.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

  • Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.

  • If you are unsure, ask the person/company that wrote the application.

  • If you are a developer, find out what library your app is using for TLS connections and test to be certain.

add more info so it can be used to answer "Is X vuln to HB" type questions
Source Link
scuzzy-delta
  • 9.4k
  • 3
  • 36
  • 55

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

  • Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.

  • If you are unsure, ask the person/company that wrote the application.

  • If you are a developer, find out what library your app is using for TLS connections and test to be certain.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

So in summary:

The only apps/services that are affected are those that use a vulnerable version of OpenSSL for TLS connections, and have TLS heartbeat support.

  • Other TLS libraries (like GnuTLS, SChannel, and JSSE) cannot possibly be affected by this particular bug, because it only exists in specific versions of the OpenSSL library.

  • If you are unsure, ask the person/company that wrote the application.

  • If you are a developer, find out what library your app is using for TLS connections and test to be certain.

even better re-wording
Source Link
scuzzy-delta
  • 9.4k
  • 3
  • 36
  • 55

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive). 1.0.1 was released on 14th of March 2012, and was fixed in 1.0.1g (which fixes the bug) was, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1. It remained present through to version 1.0.1f (inclusive). 1.0.1 was released on 14th of March 2012, and 1.0.1g (which fixes the bug) was released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.

It is hard to say exactly which apps/services are affected. This is because OpenSSL is a collection of programming code (referred to as a "library") that can be used to add TLS support to an application or system. TLS (Transport Layer Security) provides secure connections, and is best known for being the security layer behind HTTPS websites.

So if a programmer were writing a program that needed to use TLS to connect to something, they can use the OpenSSL library to add that ability to their app.

The OpenSSL library itself is constantly being improved, like many other bits of software. During this process, the Heartbleed bug was accidentally introduced in OpenSSL version 1.0.1, which was released on 14th of March 2012. It remained present through to version 1.0.1f (inclusive) and was fixed in 1.0.1g, released on 7th of April 2014 .

This means that any application that uses those OpenSSL versions for TLS is potentially affected. No doubt the affected developers have fixes in progress.

The fix has since been "backported", meaning that it has been added to versions of OpenSSL prior to 1.0.1g. This is a good thing, and is commonly done for vulnerabilities, but has the side effect of making it harder to tell if an app is vulnerable (since you can't tell just by looking at the OpenSSL version).

To address your specific questions:

  • SSH is not affected (SSH is a different protocol to TLS)
  • HTTP is not affected (HTTP is also a different protocol to TLS), meaning that a HTTP-only server will not be affected.
  • Note that it's possible to provide HTTPS using other libraries - so Microsoft IIS Web Servers (which don't use OpenSSL) can provide HTTPS without being affected.
edits for clarity
Source Link
scuzzy-delta
  • 9.4k
  • 3
  • 36
  • 55
Loading
Source Link
scuzzy-delta
  • 9.4k
  • 3
  • 36
  • 55
Loading