Security. Due Diligence. Audit. Three words which should be on the minds of each and every Contractor in the Mortgage Field Services Industry today. Take security. When I communicate with High Value Sources, I run PGP Keys. For example, my Public PGP Key is stored on the MIT Servers in addition to quite a few others. If you want to send me encrypted email that even the National Security Agency (NSA) will have extreme difficulties breaking in say 10,000 years, you load my PGP Key and fire at will.
Heartbleed is a flaw in OpenSSL, an open-source encryption technology that is used by an estimated two-thirds of Web servers. It is behind many HTTPS sites that collect personal or financial information. These sites are typically indicated by a lock icon in the browser to let site visitors know the information they’re sending online is hidden from prying eyes.
Cybercriminals could exploit the bug to access visitors’ personal data as well as a site’s cryptographic keys, which can be used to impersonate that site and collect even more information.
Matthew Green, a Cryptographer and Professor at Johns Hopkins University stated,
Heartbleed is a surprisingly small bug in a piece of logic that relates to OpenSSL’s implementation of the TLS ‘heartbeat’ mechanism. The bug is present in OpenSSL versions 1.0.1 through 1.0.1f (and not in other versions). Sadly, these versions have seen a great deal of adoption lately, because security professionals have been urging developers to implement more recent versions of TLS (1.1 and 1.2). Deployment of TLS 1.2 currently stands at about 30% of the SSL Pulse data set. Many of those servers are likely vulnerable.
The problem is fairly simple: there’s a tiny vulnerability — a simple missing bounds check — in the code that handles TLS ‘heartbeat’ messages. By abusing this mechanism, an attacker can request that a running TLS server hand over a relatively large slice (up to 64KB) of its private memory space. Since this is the same memory space where OpenSSL also stores the server’s private key material, an attacker can potentially obtain (a) long-term server private keys, (b) TLS session keys, (c) confidential data like passwords, (d) session ticket keys.
The fix? Simple as Green points out and we implemented when it came up in the Google Developer forums I work in,
+ /* Read type and payload length first */ + if (1 + 2 + 16 > s->s3->rrec.length) + return 0; /* silently discard */ + hbtype = *p++; + n2s(p, payload); + if (1 + 2 + payload + 16 > s->s3->rrec.length) + return 0; /* silently discard per RFC 6520 sec. 4 */ + pl = p;
The reality is that with National, Regional and Otherwise Unspecified Order Mills whom many are Members of the National Association of Mortgage Field Services (NAMFS) Regime more worried about how to defraud Contractors than how to protect homeowner’s Confidential Material, it is hard to meaningfully make change. This change; the line item fix, should happen NOW if OpenSSL is being implemented in any way, shape or form!