I have seen the other thread on this but feel it has gone far enough into the detail to lose important, simple, information like this. If you are technical enough to check the sites for their SSL then please report back. This morning I have checked both my bank websites and discovered the following:

SCB - OpenSSL issued by Entrust - WARNING - http://www.entrust.com/openssl-heartbleed-bug/ - Summary: Depends on how up to date the server is

KasikornBank - Symantec SSL issued by Verisign - OK

If you can check sites you use we can make this a quick, go to, resource for ThaiVisa members.

SCB has maintenance planned on Saturday the 12th, so hopefully they will fix this.

Which tool did you use to check ?

According to this, Bangkok Bank have "taken steps to reduce ongoing risk" but that doesn't inspire much confidence since many credit card payments are processed here. Bangkok Bank would do well to post an assurance on their web site - which currently makes no mention of Heartbleed.

https://lastpass.com/heartbleed/?h=ipay.bangkokbank.com

"That server is known to use OpenSSL and could have been vulnerable. The SSL certificate for www.ipay.bangkokbank.com was regenerated 1 day ago at Apr 8 18:22:02 2014 GMT which is likely regenerated after heartbleed bug was published, they've updated their SSL certificate which likely means they've taken steps to reduce their ongoing risk from heartbleed"

According to this, Bangkok Bank have "taken steps to reduce ongoing risk" but that doesn't inspire much confidence since many credit card payments are processed here. Bangkok Bank would do well to post an assurance on their web site - which currently makes no mention of Heartbleed.

https://lastpass.com/heartbleed/?h=ipay.bangkokbank.com


"That server is known to use OpenSSL and could have been vulnerable. The SSL certificate for www.ipay.bangkokbank.com was regenerated 1 day ago at Apr 8 18:22:02 2014 GMT which is likely regenerated after heartbleed bug was published, they've updated their SSL certificate which likely means they've taken steps to reduce their ongoing risk from heartbleed"

That might be, but that is not the Internet Banking Site from Bangkok Bank !

And I get different results if I click your link

According to this, Bangkok Bank have "taken steps to reduce ongoing risk" but that doesn't inspire much confidence since many credit card payments are processed here. Bangkok Bank would do well to post an assurance on their web site - which currently makes no mention of Heartbleed.

https://lastpass.com/heartbleed/?h=ipay.bangkokbank.com

"That server is known to use OpenSSL and could have been vulnerable. The SSL certificate for www.ipay.bangkokbank.com was regenerated 1 day ago at Apr 8 18:22:02 2014 GMT which is likely regenerated after heartbleed bug was published, they've updated their SSL certificate which likely means they've taken steps to reduce their ongoing risk from heartbleed"

That might be, but that is not the Internet Banking Site from Bangkok Bank !

And I get different results if I click your link

lastpass.JPG

Strange - just rechecked and got the same result as before, attached - is your temporary internet folder empty?

55555555555555

Yes my Temp Internet Folder is empty as I run my browser in a Sandbox and after I close my Browser the Sandbox is cleared.

I haven't been on that lastpass site before, until you posted that link. At the moment there are so many tools to check in circulation but none of them is really 100% trustworthy it seems

Can you check the Internet Banking site of Bangkok Bank and see what that gives ??

SCB has maintenance planned on Saturday the 12th, so hopefully they will fix this.

Which tool did you use to check ?

I just hovered over the padlock icon, got the certificate issuing company name and then searched for their SSL. Entrust uses OpenSSL but has the advice that up to date versions are OK. Therefore it comes down to the banks to issue advice. Nice spot on their maintenance announcement.

^Yeah but even if they upgrade their SSL Certificate doesn't mean that they are safe (but that discussion belongs in the other Thread )

If you use Google Chrome there is now a plug in available https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic

These tests below are for actual heartbleed memory data.

Ignoring certificates or SSL versions, just reporting where the vulnerability is witnessed.

Lots of banks have no SSL enabled on their main website which makes them immune, this is generally fine since no data collection or logins are enabled.

They use different servers for the login systems that do run SSL.

I am checking main domains and internet banking domains separately.

Any that are safe now could have been previously compromised, so security certificate and password changes can be a good idea.

www.tmbbank.com - VUNERABLE!!!!! but this is website not account logins, hopefully no sensitive data....still not good...

www.tmbdirect.com - not vunerable now

scb.co.th - No SSL by the look of it, Safe

scbeasy.com - not vunerable now

scbbusinessnet.com - not vunerable now

kasikornbank.com - No SSL by the look of it, Safe

usermanagement.kasikornbank.com - not vunerable now

online.kasikornbankgroup.com - not vunerable now

bizibanking.bangkokbank.com - not vunerable now

bangkokbank.com - not vunerable now

ibanking.bangkokbank.com - not vunerable now

dimenxion.bangkokbank.com - not vunerable now

www.uob.co.th - No SSL by the look of it, Safe

uobcyberbanking.com - not vunerable now

bib.uob.co.th - not vunerable now

www.krungsri.com - not vunerable now

www.krungsrionline.com - not vunerable now

what about the kbank payment gateway https://rt05.kasikornbank.com/pgpayment/payment.aspx which i just used to order food by phone?!

Qualys SSL Labs has a tool to check SSL vulnerability.

https://www.ssllabs.com/ssltest/index.html

Use the exact web address that you use to access the online banking account.

Kasikorn Bank, Krungsi Bank and Bangkok Bank all have a "B" rating.

https://www.ssllabs.com/ssltest/analyze.html?d=online.kasikornbankgroup.com

https://www.ssllabs.com/ssltest/analyze.html?d=rt05.kasikornbank.com

https://www.ssllabs.com/ssltest/analyze.html?d=krungsrionline.com

https://www.ssllabs.com/ssltest/analyze.html?d=ibanking.bangkokbank.com

Dharm... aspx at the end so thats safe without needing to check. IIS doesnt use openSSL.

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

Dharm... aspx at the end so thats safe without needing to check. IIS doesnt use openSSL.

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

Not necessarily true that they run IIS

https://wiki.archlinux.org/index.php/ASP.NET_with_Apache

http://weblogs.asp.net/israelio/archive/2005/09/11/424852.aspx

True...but if any bank is running .net on apache they should be closed down immediately since it is possible but not tested or secured for environments like banking!

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

I use the Thaiexpat.TV service but the server according to both the following two tools:

https://sslanalyzer.comodoca.com/heartbleed.html

https://filippo.io/Heartbleed/

is vulnerable to the Heartbleed attack!

I emailed them a few days ago but I haven't received a reply from them. I know there is a lot of chatter that many of these checking tools aren't accurate but these seem to be two of the best.

OpenSSL Heartbleed bug sniff tools are 'BUGGY' – what becomes of the broken hearted?

Software that claims to detect the presence of OpenSSL's Heartbleed bug in servers, PCs and other gear may falsely report a system to be safe when users are actually in danger, according to a security consultancy.

http://www.theregister.co.uk/2014/04/17/heartbleed_detection_glitches/

Please try the filippo one with www.thaiexpat.tv .

Sent from my Nexus 7 using Thaivisa Connect Thailand mobile app

Dharm... aspx at the end so thats safe without needing to check. IIS doesnt use openSSL.

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

But what if they have a Linux/OpenSSL load balancer sitting in front of the web servers that's hosting the certificate? In that case, it could have still been leaking private keys for 6 months.

None of the online heartbleed checkers we've used were able to successfully detect Windows servers with SSL certs hosted by vulnerable Linux load balancers on the front end.

Good point imho.... although that is a strange setup that would introduce issues anyway. Most load balancers just pass data through without modifying and ssl support on the loadbalancer typically combined with matching support on the server.

If a load balanced server was vunerable a tool like mine would detect it since it basically simulates an attack and sees what comes back. If no data arrives then it is safe since an attacker would get the same. Which may happen if an openssl load balancer simply passes the heartbleed request onto iis to respond to, making the scenario immune. Or the load balancer may respond itself, depends on setup.

However I will admit my knowledge on this exact scenario is limited since I keep windows machines well away from my hosting environments.

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

Good point imho.... although that is a strange setup that would introduce issues anyway. Most load balancers just pass data through without modifying and ssl support on the loadbalancer typically combined with matching support on the server.

If a load balanced server was vunerable a tool like mine would detect it since it basically simulates an attack and sees what comes back. If no data arrives then it is safe since an attacker would get the same. Which may happen if an openssl load balancer simply passes the heartbleed request onto iis to respond to, making the scenario immune. Or the load balancer may respond itself, depends on setup.

However I will admit my knowledge on this exact scenario is limited since I keep windows machines well away from my hosting environments.

Sent from my GT-N7100 using Thaivisa Connect Thailand mobile app

Most of the big cloud hosters (AWS, Rackspace, Softlayer etc) have load balancers with the ability to offload all SSL negotiation to the load balancer - the idea being that it makes scaling out that much easier and faster as there no need to go through the whole CSR/Approve/Install process for each new instance added to the balanced set. It also makes cert renewal much easier too - one single instance (the LB) to update, rather than 10's, 100's or even 1000's of balanced instances to do one by one

I think you'll find this is more common than not for large portals that have been designed to be massively scalable, and be DOS resistant.