A bit of explanation - TLS replaced SSL as a superset some time back....e.g. the progression went SSL 1.0 -> SSL 2.0 (1995) -> SSL 3.0 (1996) -> TLS 1.0 (1999) -> TLS 1.1 (2006) -> TLS 1.2 (2008). So saying ASE was using SSL was often more accurate at saying ASE was using TLS 1.0. There are recent attacks showing how TLS 1.0 could be vulnerable. At issue is the fact that TLS (and SSL) protocols automatically negotiated down the most commonly supported level until recently - e.g. if you attempted to connect at TLS 1.1, it would silently downgrade to TLS 1.0 which was vulnerable. As a result, later TLS 1.x versions prohibited downgrades. In June of this year (2016), browsers are required to stop supporting TLS 1.0 - and PCI compliance will dictate this - not only for browsers, but POS terminals as well that might be vulnerable.
What it means for ASE depends. If your browser connects to a middle tier web server/app server using TLS 1.1 or 1.2 and then the app server connect to ASE - they you are fine providing you are not concerned about the ability to attack the connection between app server and ASE - e.g. the app will work, however, you may have issues with certifications such as PCI. However, if your browser runs javascript or other logic that attempts a direct SSL connection to ASE, then there will be problems until ASE supports TLS 1.1 or 1.2.
Engineering is aware of this and trying to find resources to provide support for later revs of TLS. As with anything, the more customers impacted that engineering is aware of, the higher the priority. So, as Ryan states, if you need TLS 1.1 or TLS 1.2 support, please open an incident on BC-SYB-ASE and request TLS 1.1 or 1.2 support as needed and dates needed by.