Welcome to nsane.forums

Welcome to nsane.forums, like most online communities you need to register to view parts of our community or to make contributions, but don't worry: this is a free and simple process that requires minimal information. Be a part of nsane.forums by signing in or creating an account.

  • Access special members only forums
  • Start new topics and reply to others
  • Subscribe to topics and forums to get automatic updates

Search the Community

Showing results for tags 'ssl'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Found 20 results

  1. Despite 39 percent of businesses suffering an SSL-based attack in 2016, only 25 percent feel confident in their ability to deal with one according to a new study. The report from cyber security company Radware shows that cyber attacks are becoming the norm, with 98 percent of organizations experiencing some form of attack in 2016. SSL attacks though are of particular concern. SSL provided the backbone of eCommerce, though the Heartbleed attacks of three years ago have led many companies to switch to alternatives like TLS. For attackers though SSL offers a way to mask attack traffic and thwart malware detection in both network and application level threats. The use of SSL makes it harder to detect attacks as many existing solutions don't inspect SSL traffic because of the difficulty of decrypting it. Radware's data suggests SSL attacks have increased by 10 percent over the last year. The report's authors note, "SSL is both a blessing and a curse: blessing because it solves the privacy problem and secures the communication of sensitive information; curse because it creates new blind spots and vulnerabilities into an enterprise IT infrastructure." In order to protect themselves Radware say that organizations should aim to decrypt and re-encrypt SSL sessions to enable security inspection of both clear and encrypted traffic while maintaining privacy of content en-route. Any SSL inspection solution also needs to be able to selectively forward traffic to one or more security solutions. This needs careful implementation though as any solution must dynamically define filters that intercept and open traffic for inspection even if it flows through non-standard TCP ports (such as HTTPS port 443). To avoid turning the SSL traffic inspection solution into a target itself, it must not perform like a proxy or have its own IP address. Any solution must also be scalable to cope with varying levels of traffic, and ensure traffic is always forwarded to the fastest-responding available security servers. You can find out much more in the full report which is available from the Radware website. Source
  2. Kaspersky is moving to fix a bug that disabled certificate validation for 400 million users. Discovered by Google's dogged bug-sleuth Tavis Ormandy, the flaw stems from how the company's antivirus inspects encrypted traffic. Since it has to decrypt traffic before inspection, Kaspersky presents its certificates as a trusted authority. If a user opens Google in their browser, for example, the certificate will appear to come from Kaspersky Anti-Virus Personal Root. The problem Ormandy identified is that those internal certificates are laughably weak. "As new leaf certificates and keys are generated, they're inserted using the first 32 bits of MD5(serialNumber||issuer) as the key ... You don't have to be a cryptographer to understand a 32bit key is not enough to prevent brute-forcing a collision in seconds. In fact, producing a collision with any other certificate is trivial," he writes here. Ormandy's bug report gave, by way of demonstration, a collision between Hacker News and manchesterct.gov: "If you use Kaspersky Antivirus in Manchester, Connecticut and were wondering why Hacker News didn't work sometimes, it's because of a critical vulnerability that has effectively disabled SSL certificate validation for all 400 million Kaspersky users." Kaspersky fixed the issue on December 28. Source
  3. Chrome 55 (latest beta build available via Chrome Canary) is introducing the ability to specifically flag a HTTP website as non secure. HTTP Website in Chrome 55 This is a pretty big step change in making encryption much more important for every site owner. There has been talk that Chrome will also introduce a warning for sites containing password fields but no HTTPS. At this time there is no difference with the standard HTTP website “Not Secure” warning. HTTP Website in Chrome 55 with password field It looks as though Chrome are slowly encouraging owners to go HTTPS even if they don’t think it is needed. More prominence is also given to sites deploying correctly configured HTTPS certificates. HTTPS Website in Chrome 55 Finally EV Certificates continue to highlight the organisation details providing additional validation and trust. EV Certificate in Chrome 55 Article source
  4. I occasionally see people ask why we're calling it TLS 1.3 when so much has changed, and I used to simply think that it was too bikesheddy to bother changing at this point. However, now that we've redone negotiation, we have new TLS 1.3+ only cipher suites. The old are not compatible with the new (new codepoints needed for old ciphers) and the new are not backwards compatible with the old (they'll just be ignored). We actually risk misconfiguration in the future if the distinction isn't made clear. I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major version seems more appropriate. Note that contrary to what some people seem to think, version numbers are not completely without meaning. To someone who doesn't really know/care that much what TLS is, making sure to use the latest major version of a security protocol carries more weight than a minor version. It also makes it clear that there are new features here (e.g. 0-RTT). There's some de facto standardization in versioning which does carry some useful information. We're not just dealing with programmers here; this stuff needs to be clear for managers and non-professionals. If we want to get everyone upgraded eventually, messaging is important. Specific proposed changes: * Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2) * Keep the version ID as { 3, 4 } (already weird counting; changing risks more intolerance) * Rename the new cipher suites to have a "TLS2_" prefix to be less confusing for the registry & end configuration * Add a sentence noting the development history here, and that all documents that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2) This is a relatively simple set of changes to make that I think can be beneficial in the long run, and is essentially just editorial. Rebranding might not be something everyone really wants to bother with, but if we expect this to be in use for a decade or more (whether we like it or not), we should probably make sure to be as clear as possible at the start. Article source
  5. Monitoring SSL Traffic Now Everyone's Concern: A10 Networks As the uptake of SSL grows, Tim Blombery, systems engineer at A10 Networks, said threat actors are increasingly leveraging SSL-based encryption to hide malicious activity. As usage of Secure Sockets Layer (SSL) moves beyond the login page or banking website and out into the wider web, Tim Blombery, Systems Engineer at security firm A10 Networks, believes monitoring SSL traffic should now be a concern for almost every company. Blombery believes that encryption is necessary to protect online data in transit from being compromised, but noted threats are always evolving. With over half of the traffic on the internet now encrypted with SSL, he said bad actors are leveraging SSL-based encryption to hide malicious activity from existing security controls and technology. Consequently, Blombery said this means enterprises have lost the ability to look at the traffic that is traversing their network, opening themselves up to attack. "This is becoming an increasing vector for attacks and compromises of networks," he said. "I think SSL offers a very pertinent threat at the moment." Blombery said attacks often arrive via the likes of a Gmail account, which is encrypted to the desktop, with someone unwittingly opening a file containing a cryptolocker. "Off they go, they've compromised that particular system and potentially the entire network," he said. "Having SSL visibility is vital for Australian enterprises and I think they're just starting to get that idea." As it often takes a breach for someone to jump on board with a specific security solution, Blombery said more and more Australian businesses are starting to become aware of the need to monitor SSL traffic because they have either been affected or heard of someone who has been affected by this sort of attack. "There are serious breaches regularly, but everyone's breach is serious for them," he said. "Even the smallest of companies needs to be security conscious these days." The hardware for SSL inspection is a device sitting on the perimeter taking the SSL offload, the company said, which decrypts traffic and then passes it on to the firewall or IPS. "Once those devices do their job, they hand the traffic back to our device to re-encrpyt and send on to the destination -- that's traffic coming in or out," Blombery said. With mandatory breach reporting laws not yet in place in Australia, Blombery noted that even if there was an abundance of breaches due to SSL traffic not inspected, the public might not even know about it. "For the individuals affected, you certainly want to know if your account or any account is being breached -- you should be informed," he added. "A lot of people silly enough have the same password for everything or the same subset of passwords, so if a company you're working with has been breached and you don't have that visibility, then potentially all of your online identity can be compromised." A10 Networks recently completed its first acquisition, scooping up cloud application delivery firm Appcito. "It really expands us into not just the cloud but as a cloud native company as well," Blombery said. "Appcito brings load balancing as-a-service, in the cloud functionality that we'll be able to tie in with our own existing infrastructure based functionality, and allow for common policy to support the applications whether they're in the datacentre or in the public cloud somewhere." Blombery said Appcito is already embedded within A10 and are essentially the cloud decision of the organisation. Source
  6. SSL is a great way to encrypt and protect data transferred between servers or between browser and servers from any attempt to spy on the data on its way or as known as man in the middle attack, we will focus in this article on HTTPS protocol and the method to attack it and proper way to fight against this attacks. Is HTTPS that important ? first let’s declare the importance of using SSL with HTTP traffic. Imagine the next scenario. you are trying to login to your bank account with your laptop connected in your wifi and you know its secure its you and your little sister who connect in the same wifi, secure right? ? but your wifi uses weak password or vulnerable to exploits, so someone gain access to the same wifi and with a simple tool he can run a packet sniffer and catch all your and your sister’s traffic and look into your password and even change the data if he wants. Imaging the same scenario but your bank is using HTTPS, when you access the website you receive the website certificate signed and your browser validate the signature to make sure that certificate belongs to the website, then your browser encrypt all data then send the encrypted data to the server and do it vice versa, so if our attacker try to sniff the data all what he will get is the encrypted data, cool right ? Lets be honest no one is 100% secure and SSL had a tough couple of years from attacks like Heartblead, DROWN and POODLE , this attacks target the SSL it self , all what you have to do to mitigate this attacks is to be up to date always and apply vendors patches as it appears. But what about sniffing dangerous, does using HTTPS solve it? the answer is not completely, some researchers tried to sniff HTTPS packages by inventing tools like SSL sniff and SSL strip. SSL sniff :- SSL sniff is tool programmed by Moxie Marlinspike based on vulnerability he discovered, let us quickly describe it. When you request a website for example ( example.com ) as we said before you receive the example.com certificate the certificate must be issued by one of the valid vendors, so if follow certificate chain from the root certificate ( root certificate embedded in the browsers by default) to the leaf certificate ( example.com certificate) but what if leaf certificate tried to generate another certificate in the chain? lets say to website like paypal.com! the surprising thing that it worked and no one bothered himself by checking that leaf certificate generated another leaf certificate, but how attacker can use this? the website still be example.com not paypal.com, and that’s why he made SSL Sniff tool. by intercepting the traffic (man in the middle attack) you will intercept the request to paypal.com and with SSL Sniff, then you can generate the paypal.com certificate from the leaf certificate you have example.com and send it back to the browser instead of original paypal.com certificate, when the browser try to validate the certificate it will pass because the chain is correct, then any request between the browser and the server will be signed by the certificate you generate so you can decrypt the data as you want, and then re-transfer it by using the original paypal.com certificate, Boom. fortunately it had been fixed and now the leaf certificate cannot generate another certificate. SSL Strip:- Another tool by the same man Moxie Marlinspike. but in this time he came up with another trick using man in the middle, but what if he changed the request to http instead of HTTPS, and he will request the website on behalf of the user using HTTPS but between the attacker and the user its plain http, and the user will not be so suspicious to notice the difference in his browser. How to defend against this techniques ? Using HTTPS only will not solve it completely, even if you restricted the connection to HTTPS only in the server side, the attacker still can force user to use HTTP by using SSL strip and you will not notice the request still HTTPS in your end, and here HSTS header comes. HTTP Strict Transport Security (HSTS) is a web security policy mechanism it tells the browser that he must only connect to the website using secure HTTPS connection. just send header like this from your server. Strict-Transport-Security: max-age=31536000 The key is Strict-Transport-Security that tells the browser or any other agent to strict the transportation to ssl . the value is maximum age to use this header in seconds 31536000 equal to one non-leap year. Then the user agent will automatically change any url to HTTPS before it send it to the server allowing only secure connections. Bottom line , using HTTPS comes with responsibilities , you must be up to date , patch your system if any vulnerability comes up, renew your certificate on time and don’t forget to use Strict-Transport-Security Policy. Article source
  7. SSL malware samples, C&C servers, grow manifolds Malware statistics from January 2014 to December 2015 The overall numbers of malware families employing SSL to protect their C&C server communications has gone up dramatically, a Blue Coat report reveals. Researchers say that both the number of malware samples detected each month and the total number of active C&C servers are on the rise. For both categories, the security firm says it observed a huge spike in SSL deployment starting with the end of 2015. The company says it analyzed cyber-criminal activity from January 2014 up to December 2015 and has used data from the SSL Blacklist site which keep tracks of abused or bad SSL certificates, often deployed in criminal activities. The report analyzed detections and the infrastructure of common malware families known to implement SSL to protect themselves. Some of these malware variants included names such as Dridex, KINS, Shylock, URLzone, TeslaCrypt, CryptoLocker, TorrentLocker, CryptoWall, Upatre, Gootkit, Geodo, Tinba, Gozi, VMZeus, Redyms, Vawtrack, Qadars, Spambot, Emotee, and Retefe. Number of C&C servers using SSL grows 200 times Researchers discovered that during the two-year period they analyzed, malware samples, employing SSL or not, have both gone up. Malware samples deploying SSL have always been smaller in numbers when compared to the overall number, but something changed in October 2015, when the number of malware using SSL has increased manifolds. Blue Coat researchers saw SSL malware numbers going from 500 samples detected per month to 29,000 in the span of two months. The same thing happened with the number of C&C servers that used SSL-protected connections to talk to their bots, which jumped from around 1,000 servers in Q1 2015 to 200,000 in Q3 2015. Blue Coat included considered C&C server any website or IP that crooks used as coordination points, malware download sites, data exfiltration points, and other Web-based operations points. SSL malware recorded a big jump just before the holidays last year "Looking at the timeframe of the spike, it coincided with the onset of the holiday season. As such, the spike could have been attributed to the launch of one or more large-scale campaigns with infrastructures based on those malware families," Blue Coat researchers noted. Researchers also pointed out that the number of C&C servers grew well before the malware sample spike, something that is realistic since criminal gangs need to set up their C&C server infrastructure before initiating malware campaigns. "What’s more, the massive jump in C&C servers is likely attributed to the malware utilizing Domain Generating Algorithms (DGA) for short-living Domains to build out a C&C infrastructure," the Blue Coat team said, explaining the humongous jump in numbers regarding C&C server numbers. Article source
  8. New research suggests encrypted traffic is becoming the go-to method for threat actors to hide malicious code. The use of encrypted traffic to disguise malware attempting to infiltrate user devices and enterprise networks has "significantly" risen over the past year, researchers say. According to cybersecurity firm Blue Coat, there was a visible increase in the use of SSL/TLS encryption standards born out of privacy worries. However, while many individuals are now using these protocols whenever possible, it appears that threat actors are also harnessing SSL to disguise their activities. On Sunday, the team said in a press release that over 2015, analysis revealed a 58 times increase in SSL-cloaked traffic in command and control servers (C&C), which are used to relay commands remotely to malware which has infected computer systems. In addition, Blue Coat says there was a 200 times increase in C&C servers using SSL last year, indicating "that SSL/TLS will be increasingly used in the future to hide attacks." This spike in usage will likely cause concern for IT and security professionals. Encryption, in itself, is a beneficial way to protect user privacy and keep communication masked and kept away from spying eyes -- whether this is law enforcement, snooping governments or cyberattackers -- however, it can also be used by threat actors to increase the severity of their attacks. Michael Fey, president and COO of Blue Coat Systems commented: Last week, Blue Coat announced support for SCADA (Supervisory Control and Data Acquisition) environments and additional anomaly detection in the firm's range of security solutions. Article source
  9. StartSSL faces another issue that lets attackers obtains SSL certificates for domains they don't own StartEncrypt service logo Thijs Alkemade, a security researcher for Dutch security firm CompuTest, has discovered multiple design and implementation flaws in StartEncrypt, a tool created by Israeli company StartCom for issuing free SSL certificates. StartCom, the CA (Certificate Authority) behind the StartSSL service, launched the StartEncrypt project on June 4, inspired by the success of the Let's Encrypt project. Users who want to deploy free StartSSL certificates can take advantage of their StartEncrypt offering. They only need to download a Linux client they're supposed to upload to their servers. This client performs a domain validation process, informs the StartSSL service, which then issues and installs an "Extended Validation" SSL certificate for the domain it has found running on the server it has just checked. StartEncrypt contains design and implementation flaws According to CompuTest, this validation process is flawed, and through a few tricks, it allows server owners to receive SSL certificates issued for other domains, such as Facebook, Google, Dropbox, etc., which can be sold on the black market or used in man-in-the-middle attacks. The first issue Alkemade discovered in the StartEncrypt client was a design-related problem linked to the fact that users could manually configure the folder from where the client would download a signature from the server. An attacker would only have to point the tool to a folder on their server holding the signature of another domain. These domain signatures can be extracted from any sites that allow users to upload files: GitHub, Dropbox, etc.. StartEncrypt bug combined with OAuth 2.0 protocol condition The second issue is far more serious because it enabled an attacker to obtain SSL certificates for even more domains than the ones before. According to the researcher, one of the API verification calls contains a parameter dubbed "verifyRes," which takes a URL as input. This means the client was exposed to Open Redirect vulnerabilities. In other words, an attacker could forge this request and point the tool off-domain to a server not under their control. But this feature is not that easily exploitable. The domain URL to which the attacker needs to point the tool must (1) allow users to upload files and serve them back in raw format; or (2) to contain an Open Redirect issue of its own. While the first condition was quite rare, the second was not. All websites that support OAuth 2.0, a specification that powers social login features, must allow open redirects for the protocol to function properly. A crook leveraging this OAuth 2.0 condition and the StartEncrypt client could fool the StartSSL service into issuing a free SSL service in their name for any site that provides OAuth 2.0 support, such as Facebook, Twitter, Yahoo, Microsoft, and so on. Multiple other issues discovered as well Additionally, CompuTest also found that StartEncrypt doesn't check its own server's certificate for validity when connecting to the API, meaning crooks could receive verification requests and issue false SSL certificates for users trying to use StartEncrypt. The API also doesn't check the content type of the file it downloads for verification, so attackers can obtain certificates in the name of third-party websites where users can upload their avatars. At the same time, the certificate private key, which must be private, is stored with 0666 permissions in a public folder, so everyone could read it. Furthermore, just like Let's Encrypt, StartEncrypt is vulnerable to a Duplicate-Signature Key Selection attack. "In our opinion, StartCom made a mistake by publishing StartEncrypt the way it is," CompuTest's Christiaan Ottow explains. "Although they appreciated the issues for the impact they had and were swift in their response, it is apparent that too little attention was paid to security both in design (allowing the user to specify the path) and implementation (for instance in following redirects, static linking against a vulnerable library, and so on). Furthermore, they didn’t learn from the issues LetsEncrypt faced when in beta." StartCom has released a new version of the StartEncrypt Linux client, with the same version number 1.0.0.1. CompuTest says they reported other issues to the service, which are still being corrected and will be fixed in future updates. Back in March, StartSSL faced a similar issue with its general service, which also allowed crooks to receive SSL certificates for domains they didn't own. Article source
  10. Many SSL VPNs don't use the latest encryption tech Most SSL VPNs don't get a passing grade Information security firm High-Tech Bridge has conducted a study of SSL VPNs (Virtual Private Networks) and discovered that nine out of ten such servers don't provide the security they should be offering, mainly because they are using insecure or outdated encryption. An SSL VPN is different from a classic IPSec VPN because it can be used inside a standard Web browser without needing to install specific software on the client-side. SSL VPNs are installed on servers, and clients connect to the VPN via their browsers alone. This connection between the user's browser and the VPN server is encrypted with the SSL or TLS protocol. Three-quarters of all SSL VPNs use untrusted certificates Researchers from High-Tech Bridge say they analyzed 10,436 randomly selected SSL VPN servers and they found that most of them are extremely insecure. They claim that 77% of all SSL VPNs use SSLv3 or SSLv2 to encrypt traffic. Both of these two versions of the SSL protocol are considered insecure today. These protocols are so insecure that international and national security standards, such as the PCI DSS and NIST SP 800-52 guidelines, have even gone as far as to prohibit their usage. Regardless of their SSL version, 76% of all SSL VPN servers also used untrusted SSL certificates. These are SSL certificates that the server has not confirmed, and that attackers can mimic and thus launch MitM (Man-in-the-Middle) attacks on unsuspecting users. High-Tech Bridge experts say that most of these untrusted certificates are because many SSL VPNs come with default pre-installed certificates that are rarely updated. Some VPNs still use MD5 to sign certificates Additionally, researchers also note that 74% of certificates are signed with SHA-1 signatures, and 5% with MD5 hashes, both considered outdated. 41% of all SSL VPNs also used insecure 1024 key lengths for their RSA certificates, even if, for the past years, any RSA key length below 2048 was considered to be highly insecure. Even worse, one in ten SSL VPNs is still vulnerable to the two-year-old Heartbleed vulnerability, despite patches being available. Out of all the tested SSL VPNs, researchers say that only 3% followed PCI DSS requirements. None managed to comply with NIST (National Institute of Standards and Technology) guidelines. High-Tech Bridge is also providing a free tool that can tell users if their SSL VPN or HTTPS website is actually doing a good job of protecting them. Article source
  11. PCI Council delays SSL abandonment date to 2018, so cruddy credit crypto continues The Payment Card Industry Security Standards Council (PCI SSC) has decided to delay the deadline for migration from Secure Sockets Layer (SSL) to Transport Layer Security (SSL). Earlier this year, the Council decided the time to make the change was June 2016, a reasonable idea given that SSL gave the world the Heartbleed, Shellshock and Poodle vulnerabilities. Now the Council says it's just too hard for retailers to make the jump. The canned statement (PDF) about the moratorium, issued deep into Friday US time, features the Council's general manager Stephen Orfei saying migration was expected to be simple, “but in the field a lot of business issues surfaced as we continued dialog with merchants, payment processors and banks.” Orfei laid some of the blame at the feet of mobile devices, saying that retailers' efforts to secure transactions made on smartphones and fondleslabs, on top of “encryption, the SHA-1 browser upgrade and EMV in the US” together make for so much work that the SSL death deadline can't be met. “We’re working very hard with representatives from every part of the ecosystem to make sure it happens as before the bad guys break in,” Orfei says. The world will therefore have to bumble along with known-to-be imperfect encryption for two years longer than planned, a period during which The Register imagines "the bad guys" will do their very best take advantage of weak encryption. The new migration deadline will be formalised in the next version of the PCI DSS standard, due in April 2016. Article source
  12. Symantec didn't really care in September, doesn't care now Google has made good on its promise and banned root certificates issued by Symantec. The ban applies to Google Chrome, Android, and several other Google products. The search giant had a bone to pick with Symantec since late September when Google discovered 23 certificates issued in its name by one of Symantec's subsidiaries. Symantec tried to explain itself by saying the certificates were issued for internal tests and got leaked under unknown circumstances by three employees, who the company eventually fired. The incident escalated towards the end of October when Google discovered 164 other Symantec certificates issued for 76 other domains, along with a huge batch of 2,458 certificates issued for yet unregistered domains. Google published a statement on its blog, the equivalent of a last warning. It appears that now Google has decided to act on Symantec's arrogance/indifference and has outright banned the Class 3 Public Primary CA root certificate operated by Symantec. Google bans Symantec root certificate after the company strays off official standards "Symantec has decided that this root will no longer comply with the CA/Browser Forum's Baseline Requirements," said Ryan Sleevi, Google Software Engineer, today on the company's Security blog. "As these requirements reflect industry best practice and are the foundation for publicly trusted certificates, the failure to comply with these represents an unacceptable risk to users of Google products." Symantec did not provide any public statement on its site regarding Google's latest decision. Mr. Sleevi said Symantec has privately told Google that the particular root certificate the company was banning was not scheduled to be used to issue any new certificates for publicly-trusted connections. Symantec also told Google that they don't "believe" any of their clients that use Symantec-issued certificates will be affected by this ban. This ban is the result of an audit Google did of Symantec's certificates after the previous two incidents. This is not the first time Google has banned root certificates from a CA (Certificate Authority), the company applying the same punishment for Dutch-based CA Diginotar back in 2011, and the CNNIC CA in March 2015. News source
  13. Symantec employees mistakenly leak test SSL certificates Symantec was forced to fire 3 employees after Google's engineers found rogue SSL certificates issued in its name used in the wild. SSL certificates are a technology through which browsers and Web service providers create a secure and authorized channel of communication. They are used billions of times each day and have become a common practice in securing communications between users and banks, online shops, social networks, and about any website that wants to protect its users and their private data from hackers and privacy-intruding government agencies. Responsible for issuing these certificates is a Certificate Authority (CA). There are numerous CAs around the world, all of which are recognized and trusted by browsers makers to issue certificates to authorized and trustworthy clients only. One of those CAs is Symantec, a cyber-security vendor known primarily for its Norton antivirus engine. Google's Certificate Transparency project was first to note the rouge SSL certs This Friday, September 18, Google's engineers working for Certificate Transparency, a project that double checks for rogue SSL certificates used in the wild, has found a series of fake Google.com SSL certificates that were issued by Symantec. These rogue certificates were also observed by DigiCert's technicians in their logs as well. What's worse is that these certificates were issued with an "extended validation" label, which means that Symantec had supposedly carried out extra checks on the client that requested the certificates to validate its real identity, as Boing Boing reports. This information was not officially confirmed by either Google or Symantec in their press releases. Google has blacklisted the certificates in question. Since they were leaked only for a day, Google and Symantec don't believe they might have been used in real-world attacks. If hackers had had more time, these rogue SSL certificates could have been used in MitM (man-in-the-middle) attacks, allowing malicious actors to intercept secure communications between users and Google-operated services, like Gmail, Google+, YouTube, and such. Not the first time rogue SSL certificates are detected in the wild This is not the first time that this has happened. In 2011, Dutch-based CA Diginotar was breached and hackers issued hundreds of fake certificates. Some of these SSL certificates (also issued in Google's name) were used by the Iranian government to spy on political dissidents. The Diginotar incident was what convinced browser makers and certificate authorities around the world to create the Certificate Transparency project. The same thing happened in December 2013, when ANSSI also mistakenly issued fake Google certificates, and at the end of March this year, when the CNNIC CA issued some unauthorized digital certificates for several Google domains. After the last incident, Mozilla and Google banned all CNNIC existing root and extended validation SSL certs. Symantec has addressed the issue by firing the employees at fault Investigating its recent incident, Symantec was quick to follow suite with Google's inquiries in this matter, fearing the ax above its head. According to their official statement, the company says that these rogue certificates were issued for tests inside the company, and they were immediately revoked when Google notified them of the leak. "We discovered that a few outstanding employees [...] failed to follow our policies," said Quentin Kiu of Symantec. "Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process. [...] As much as we hate to lose valuable colleagues, we are the industry leader in online safety and security." Source
  14. The addon will score the strength of the SSL connection. The toolbar button will change color depending on the strength of encryption from red (weak) to green (strong). The drop down window shows a detailed summary of the SSL connection. Change: The Diffie-Hellman key exchange ciphers have been removed from all of the "cipher restriction" options to mitigate the "Logjam attack". If you need the DH ciphers you can choose "all ciphers" under the security tab. Download: https://addons.mozilla.org/en-US/firefox/addon/calomel-ssl-validation/
  15. ​ At the beginning of March, a new vulnerability to SSL and TLS was announced called FREAK. This compounded the announcement last fall of POODLE that caused the PCI SSC to abruptly call SSL and “early” TLS (i.e., TLS versions 1.0 and 1.1) as no longer acceptable as secure communication encryption. ​ In April, the PCI SSC issued v3.1 of the PCI DSS and gave us their take on how to address POODLE. Their plan is to have organizations remediate SSL and “early” TLS as soon as possible but definitely by June 30, 2016. While remediating SSL and “early” TLS, organizations are required to have developed mitigation programs for these protocols until they are remediated. ​ There are some exceptions to the June 30, 2016 deadline for devices such as points of interaction (POI) but those exceptions are few and far between and still require some form of mitigation. ​ Reading the explanations for the POODLE and FREAK vulnerabilities, while they are technically possible over the Internet, they are much more realistic to be performed successfully internally. As such, these vulnerabilities are more likely to be used as part of an attacker’s toolkit when compromising a network from the inside. This is not good news as an organization’s internal network is much more vulnerable since a lot of appliances and software have SSL and TLS baked into their operation and will not be quickly remediated by vendors, if they are remediated at all (i.e., you will need to buy a new, upgraded appliance). As a result, organizations need to focus on their internal usage of SSL and “early” TLS as well as external usage. ​ The remediation of these vulnerabilities on the Internet facing side of your network should be quick. Stop supporting SSL and TLS versions 1.0 and 1.1 for secure communications. ​ While I do know of a few rare situations where taking such action cannot be taken, most organizations can simply turn off SSL and TLS v1.0/1.1 and be done with the remediation. ​ As I pointed out earlier, it is the internal remediation that is the problem. That is because of all of the appliances and software solutions that use SSL/TLS and vendors are not necessarily addressing those issues as quickly. As a result the only approach is to mitigate the issues with appliances that are at risk. Mitigation can be as simple as monitoring the appliances for any SSL or TLS v1.0/1.1 connections through log data or using proxies to proxy those connections. ​ The answer to SSL and TLS vulnerabilities are to remediate as soon as possible. If you are unable to remediate, then you need to mitigate the risk until you can remediate. ​ ​Source ​
  16. Firefox-maker Mozilla has joined Google in refusing to recognize SSL certificates issued by the China Internet Network Information Centre (CNNIC). This comes after a security biz in Egypt used a CNNIC-issued intermediate certificate to create unauthorized SSL certs that could be used to trick people into connecting to bogus, password-stealing Gmail.com or Google.com websites. Google, and now Moz, are outraged by CNNIC's sloppiness in the case. CNNIC is run by the Middle Kingdom's government, and handles the .cn domain name registry, IP address allocation and other things as well as issuing SSL certificates for encrypted websites via intermediaries. "After reviewing the circumstances and a robust discussion on our public mailing list, we have concluded that CNNIC's behaviour in issuing an unconstrained intermediate certificate to a company with no documented PKI practices and with no oversight of how the private key was stored or controlled was an 'egregious practice' as per Mozilla's CA Certificate Enforcement Policy," the Mozilla security team wrote in a Thursday blog post. As a consequence of the incident, all Mozilla products – including the Firefox web browser and the Thunderbird email client, among others – will be updated so that all CNNIC-based certificates issued on or after April 1, 2015 are considered untrusted. Mozilla said it also plans to ask CNNIC for a comprehensive list of all of its current valid certificates. Any certificates issued before April 1 that are not included on this whitelist will also be subject to potential "further action." The move comes following a similar action by Google, which said on Wednesday that it would stop recognizing the CNNIC certificate authority in a future update to its Chrome browser. As a result of these actions, Chrome and Firefox users who try to connect via encrypted HTTPS to websites that use CNNIC-issued SSL certificates will see alert messages warning them that their connections may not be secure – even for online banks, e-commerce shops, and other sites that manage sensitive information. CNNIC, which manages both China's .cn country code top-level domain and the system of internationalized domain names that contain Chinese characters, issued a declaration on Thursday condemning Google's ban: 1. The decision that Google has made is unacceptable and unintelligible to CNNIC, and meanwhile CNNIC sincerely urge that Google would take users' rights and interests into full consideration. 2. For the users that CNNIC has already issued the certificates to, we guarantee that your lawful rights and interests will not be affected. Mozilla added, though, that CNNIC could regain its standing but only after proving that it could be trusted with the responsibility of managing a root certificate authority. "CNNIC may, if they wish, re-apply for full inclusion in the Mozilla root store and the removal of this restriction, by going through Mozilla's inclusion process after completing additional steps that the Mozilla community may require as a result of this incident," the nonproifit's security team said. http://www.theregister.co.uk/2015/04/02/mozilla_revokes_cnnic_cert_trust/
  17. KickassTorrents is the first large torrent site to bump up its security and force SSL encryption for all visitors. This makes it impossible for outsiders, Internet providers included, to monitor page visits or snoop on data being sent. Like most Internet users, torrent site visitors prefer not to have their browsing habits exposed to third parties. One way to prevent this from happening is by using SSL encryption. This is supported by more and more sites, and last year Google even went as far as encrypting all searches by default. Most of the larger torrent sites such as The Pirate Bay and Torrentz also offer SSL support. However, KickassTorrents is the first to force encryption. This means that everyone who visits the site will now be sending data over a secure https connection. TorrentFreak spoke with the KickassTorrents team who told us that the new feature was implemented by popular demand. “We’re just thinking about those people who will feel safer when they know all the data transferred between them and KAT is completely encrypted. People requested it, so we respond,” the KAT team informs TF. SSL encryption will prevent one’s boss, school, or ISP from monitoring what pages are visited what data is sent or retrieved from the site. However, it’s still possible to see that the KickassTorrents domain was accessed, and how much time was spent there. Also, it’s worth emphasizing that it doesn’t anonymize the visitor’s IP-addresses in any way, as a VPN or proxy might. That said, enabling encryption is a good way for KickassTorrents to offer its users a little more security. On top of that, Google recently noted that it would prioritize SSL encrypted sites in its search results, something the site’s operators probably wont mind either. Source: TorrentFreak
  18. Banker Trojans have proven to be reliable and effective tools for attackers interested in quietly stealing large amounts of money from unwitting victims. Zeus, Carberp and many others have made piles of money for their creators and the attackers who use them, and researchers have been looking at a newer banker Trojan that has the ability to bypass SSL protection for banking sessions by redirecting traffic through the attackers’ own domains. The Trojan, which is being called either Dyre or Dyreza by researchers, uses a technique known as browser hooking to intercept traffic flowing between the victim’s machine and the target Web site. The malware arrives in users’ inboxes through spam messages, many of which will look like messages from a financial institution. The list of targeted banks includes Bank of America, Natwest, Citibank, RBS and Ulsterbank. Researchers say that much of the activity from the Trojan so far is in the U.K. When a victim opens the attached zip file in a spam message, the malware installs itself on the machine and then contacts a command-and-control server. Researchers at CSIS in Denmark located a couple of the C2 servers and discovered that one of them had an integrated money mule panel for several accounts in Latvia. The goal of the malware, of course, if to steal users’ credentials for online banking and other financial sites. Various banker Trojans go about this in different ways, and Dyreza’s creators decided to employ browser hooking to help defeat SSL. “The traffic, when you browse the Internet, is being controlled by the attackers. They use a MiTM (Man in The Middle) approach and thus are able to read anything, even SSL traffic in clear text. This way they will also try to circumvent 2FA,” an analysis by Peter Kruse at CSIS says. When users go to one of the targeted financial sites and attempt to log in, the data is intercepted by the malware and sent directly to the attackers. Victims would not have any visual cues that their data is being siphoned off or that the malware is redirecting their traffic to a domain controlled by the attackers and it’s no longer encrypted. “Here’s the kicker. All of this should be encrypted and never seen in the clear. By using a sleight of hand, the attackers make it appear that you’re still on the website and working as HTTPS. In reality your traffic is redirected to the attackers page,” anotheranalysis by Ronnie Tokazowski of PhishMe says. “To successfully redirect traffic in this manner, the attackers need to be able to see the traffic prior to encryption, and in the case of browsers, this is done with a technique called browser hooking. No DNS queries were performed for the c1sh Bank of America domain, suggesting the attackers simply appended this to the Host field in the network traffic.” The Dyreza malware has the ability to hook Google Chrome, Mozilla Firefox and Internet Explorer. Dyreza’s creators decided to employ browser hooking to help defeat SSL. Source
  19. The movement by technology companies to encrypt their respective corners of the Internet continues to gain steam as more and more are enabling SSL and other encryption technologies such as Perfect Forward Secrecy to ward off surveillance and enhance the privacy and security of user data. WordPress on Thursday became the latest to promise to encrypt its traffic by default. The popular blog and content management platform said it plans to have all wordpress.com subdomains served only over SSL by the end of 2014. “In the face of intrusive surveillance, we believe that everyone in the tech community needs to stand up and do what they can, starting with their own sites and platforms,” said Paul Sieminski, general counsel at Automattic, parent company to WordPress, Cloudup, Simplenote and other web-based development platforms. The announcement came on the anniversary of the first news reports describing the depths of NSA surveillance, also known as Reset the Netday, a coordinated movement urging websites to encrypt traffic using SSL, HSTS and PFS, applications to also deploy SSL and certificate pinning, and promoting privacy tools such as Tor for users interested in keep Web traffic private. Despite yesterday’s announcement, WordPress remains a laggard among its technology provider peers. According to the Electronic Frontier Foundation’s running tally on encryption, calledEncrypt the Web, WordPress does not support HTTPS Strict, also known as HSTS, nor does it support STARTTLS. The EFF was also unable to determine whether WordPress supports Perfect Forward Secrecy, or whether it encrypts data center links. Experts believe that web and application developers that Perfect Forward Secrecy and HSTS should be default encryption technologies in any new deployment. HSTS is a policy declaration that browsers, for example, may interact only over HTTPS connections; Perfect Forward Secrecy ensures that private session keys securing an encrypted connection are random and if one is compromised, it cannot be used to compromise other messages at a future time. “Intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised,” said Parker Higgins, an EFF activist, last November. Privacy and security advocates have long urged technology companies to encrypt traffic in order to secure communication and make government surveillance that much more difficult. The NSA’s efforts have long been facilitated by laggard technology companies who were lax in encrypting not only traffic streams, but also links between data centers which the NSA hacked in order to intercept email and other data on Yahoo and Google users. Both companies have since encrypted those links. “Just as troubling as the [snowden] revelations themselves is the fact that since last summer, little if anything has changed,” Automattic’s Sieminski said. “Despite a lot of rhetoric, our three branches of government in the United States have not made many concrete steps toward truly protecting citizens from unchecked government surveillance.” WordPress is not alone in failing to encrypt data center links; according to the EFF, other large providers such as Amazon, Apple, AT&T, Comcast, Foursquare, LinkedIn and Verizon do not. “If we’ve learned anything over the past year, it’s that encryption, when done correctly, works,” Sieminski said. “If we properly encrypt our sites and devices, we can make mass surveillance much more difficult.” Source
  20. SSL

    SSL Eye is a unique tool that detects SSL man in the middle spying, by comparing SSL fingerprints of single or multiple sites across many remote nodes that are owned and managed by EEDS located in different countries such as Singapore, USA, and Netherlands, in order to compare the results with your own fingerprint that comes through your local ISP. Additionally the tool will tell you if the site is using Extended Validation (EV) certificates or perfect forward secrecy as the key exchange mechanism such as DHE_RSA or ECDHE_RSA which is used by google. We have also implemented global shortcut keys on the application so that you can copy a site from the browser address bar and call it for instant scan to check if you are a victim of Man in The Middle Attack (MITM). Where the attacker listens to your communication channel in a public key exchange re-sends the keys on your behalf, substituting his own fake keys for the requested one, so that the two original parties (you and your bank) will still appear to be communicating with each other. Features Retrieve fingerprint of any given ssl url from single or multiple sites across the EEDS nodes and compare them with yours.Check if the site is using Extended Validation (EV) certificates.Check if the site is implementing perfect forward secrecy on key exchange.Export results into HTML report.Sound alerts for invalid certificates.Scan with global keys from clipboard without user interaction.Homepage: https://www.digi77.com/ssl-eye-prism-protection/ Download Link: http://www.digi77.com/software/ssleye/update/SSLEye_Setup.exe