{"action":"created","issue":{"url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/6537","repository_url":"https://api.github.com/repos/rapid7/metasploit-framework","labels_url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/6537/labels{/name}","comments_url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/6537/comments","events_url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/6537/events","html_url":"https://github.com/rapid7/metasploit-framework/issues/6537","id":131741085,"number":6537,"title":"Disabling Weak SSL Ciphers on reverse_https listeners","user":{"login":"ghostop14","id":12989717,"avatar_url":"https://avatars.githubusercontent.com/u/12989717?v=3","gravatar_id":"","url":"https://api.github.com/users/ghostop14","html_url":"https://github.com/ghostop14","followers_url":"https://api.github.com/users/ghostop14/followers","following_url":"https://api.github.com/users/ghostop14/following{/other_user}","gists_url":"https://api.github.com/users/ghostop14/gists{/gist_id}","starred_url":"https://api.github.com/users/ghostop14/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ghostop14/subscriptions","organizations_url":"https://api.github.com/users/ghostop14/orgs","repos_url":"https://api.github.com/users/ghostop14/repos","events_url":"https://api.github.com/users/ghostop14/events{/privacy}","received_events_url":"https://api.github.com/users/ghostop14/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2016-02-05T19:56:17Z","updated_at":"2016-02-22T15:42:55Z","closed_at":null,"body":"Is there a way to create a reverse_https handler and disable weak SSL ciphers for the HTTPS listener?  Among a days worth of attempts throughout the framework code, I've tried adding an SSLContext to reverse_http.rb to specify ciphers and disable SSLv2 and SSLv3 but the result is always the same.  nmap scans of the created handler always have the default ciphers.\r\n"},"comment":{"url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/comments/187236937","html_url":"https://github.com/rapid7/metasploit-framework/issues/6537#issuecomment-187236937","issue_url":"https://api.github.com/repos/rapid7/metasploit-framework/issues/6537","id":187236937,"user":{"login":"sempervictus","id":1331084,"avatar_url":"https://avatars.githubusercontent.com/u/1331084?v=3","gravatar_id":"","url":"https://api.github.com/users/sempervictus","html_url":"https://github.com/sempervictus","followers_url":"https://api.github.com/users/sempervictus/followers","following_url":"https://api.github.com/users/sempervictus/following{/other_user}","gists_url":"https://api.github.com/users/sempervictus/gists{/gist_id}","starred_url":"https://api.github.com/users/sempervictus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sempervictus/subscriptions","organizations_url":"https://api.github.com/users/sempervictus/orgs","repos_url":"https://api.github.com/users/sempervictus/repos","events_url":"https://api.github.com/users/sempervictus/events{/privacy}","received_events_url":"https://api.github.com/users/sempervictus/received_events","type":"User","site_admin":false},"created_at":"2016-02-22T15:42:55Z","updated_at":"2016-02-22T15:42:55Z","body":"Changing the cipher list to allow low ciphers is self-defeating. MITM on the initial socket negotiation would result in the attacker filtering out the high ciphers from the list, allowing only the low ones to pass into the the DH negotiation, then attacking the resulting context.\r\n\r\nThis needs to be configurable in the Rex Socket Params module as suggested above in order to ensure the user has enough rope to hang themselves when they screw with this.\r\n\r\nGood catch. If nobody else has cycles, i might execute this in the coming days as i've added a number of options in there anyway, and should be able to get this working pretty quick.\r\n\r\n@devs: i had submitted some work a while back allowing for configuration of the client side of a TLS connection (cert, etc). If i implement this, i'll be re-introducing those parameters and implementing for client and server sides. Is there some specific reason that we didn't end up using the client options upstream, or should i just resubmit as part of this work?"}}