Login or register


Last status update:
Date Signed Up:10/03/2010
Last Login:10/01/2016
Comment Ranking:#3508
Highest Content Rank:#1376
Highest Comment Rank:#583
Content Thumbs: 11452 total,  14739 ,  3287
Comment Thumbs: 16092 total,  19127 ,  3035
Content Level Progress: 28% (28/100)
Level 208 Content: Comedic Genius → Level 209 Content: Comedic Genius
Comment Level Progress: 10.1% (101/1000)
Level 314 Comments: Wizard → Level 315 Comments: Wizard
Content Views:513778
Times Content Favorited:1507 times
Total Comments Made:3097
FJ Points:24996
Favorite Tags: it (2) | Lost (2) | the (2)

latest user's comments

#17 - I like Mark Sheppard. Never seen Supernatural, is he a tot…  [+] (1 reply) 11/13/2014 on avg. sjw website mod 0
User avatar
#30 - MrsMcDowell (11/13/2014) [-]
He is a demon. He later becomes ruler of Hell. He's a dick, yes. But an awesome one. I loved him in Battlestar Galactica, but it's hard getting used to his actual accent instead of the Irish one.
#29 - Comment deleted 11/11/2014 on Lel. 0
#176 - The server doesn't need to accept HTTP in order for sslstrip t…  [+] (2 replies) 11/10/2014 on Addy helps you get porn 0
#177 - haheho (11/10/2014) [-]
Thats not how sslstrip works !
It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon.

An attacker in a privileged position - as mentioned - can intercept traffic when the user is in the http site and manipulate it to get a Man-In-The-Middle attack under HTTPS. An application is vulnerable if it have both HTTP and HTTPS.

I suggest you to check the PoC on blackhat DC 2009 for more info
#198 - fragman (11/10/2014) [-]
You don't really have a clue about this, do you?
In sslstrip, the attacker's machine opens a HTTPS connection to the server while relaying the decrypted information to the client using a separate HTTP session. So it seriously doesn't matter at all if the server allows HTTP or not, it only gets HTTPS requests anyway (by the attacker).
If an application(!) requires HTTPS, it doesn't work (obviously, since functionality wouldn't be provided by the HTTP session given by the attacker), that is correct. However, with web browsers and therefore websites this isn't the case. If it were that easy, sslstrip wouldn't be that big of an issue. The only real countermeasures for sslstrip is using HSTS (as mentioned) which still leaves some weaknesses or better blocking TCP 80 on your client's network