Jump to content
LL Medico Diapers and More Bambino Diapers - ABDL Diaper Store

nycdl

Members
  • Posts

    2
  • Joined

  • Last visited

Profile Information

  • Real Age
    35

Recent Profile Visitors

1,930 profile views

nycdl's Achievements

Newborn

Newborn (1/7)

0

Reputation

  1. Thanks DailyDi. I did see the popup (from FireFox addon called CertPatrol) that told me of the certificate change. From what I remember a few weeks ago, I tried to change http to https for the site, but it didn't work (because the SSL/TLS document root was different than http). Now it does (mostly). While the certificate is great (even though it has the domain name in there, which is acceptable if you are paying for it), the server configuration fails Qualys's tests, as seen at https://www.ssllabs.com/ssltest/analyze.html?d=dailydiapers.com&hideResults=on In somewhat related news: http://www.bbc.co.uk/news/technology-25118156 (BBC News - NSA 'planned to discredit radicals over web-porn use') Also, something to note, Firefox is telling me the login is insecure (see attachment). Thanks again! PS: I wouldn't use RC4... (summary: you could get sued (I know, unlikely), but it's also insecure, and, as far as I know, the BEAST attack is now considered less of a priority than perfect forward secrecy, which you kind of have): http://arstechnica.com/tech-policy/2013/11/jury-newegg-infringes-spangenberg-patent-must-pay-2-3-million/ and http://threatpost.com/microsoft-warns-customers-away-from-sha-1-and-rc4/102902
  2. Hi. Lots of stuff on here... just thought I'd offer up my opinions (whether or not unique, in no particular order): 1) it doesn't have to cost money. We can verify it is the right site without a paid certificate authority signature (unless the self-signed server and certificate authority private keys were compromised (assuming you would create your own CA key pair, which I would generate and keep offline separately)) 2) it is relatively easy to set up, especially considering it's already there (see web server best practices link below) 3) while there is no guarantee of security, there is a concept known as defense in depth that says secure everything you can to minimize risk. "I reiterate my point.... security on the internet DOES NOT EXIST. If you want a secure machine, remove the network card and do not connect to the internet ever." -- agreed: http://support.microsoft.com/kb/93362. Also another fun read http://www.truecrypt.org/docs/security-model if anyone believes in real practical security. 4) It is unreasonably difficult (nothing is ever impossible given evolution of Internet security) that one can sniff the traffic assuming (among other things, of course): a) you are using at least 1024-bit RSA key pair (preferably 2048) because 768 has been factored years ago - https://blogs.rsa.com/rsa-768-factored/ , you are using Diffie-Hellman ephemeral keys (as configured in the web server) so as to create an independent session key that can't reasonably be decrypted later with a compromised server private key, c) that the visitor to the web server (client) is using the correct certificate authority key, if applicable (as opposed to an employer's own certificate authority that intercepts all connections), d) the host is not compromised (virus, key logger, kernel module, etc.), e) that you connect to the correct IP and that https is forced (there is a known attack of stripping the s in https), f) there are industry standard best practices that can be verified independently: https://www.ssllabs.com/projects/best-practices/index.html and https://www.ssllabs.com/ssltest/index.html), g) the application generating the key pair has acceptable entropy (which can be verified through a couple of sites) and is not weak 5) I agree with the hostname issue. All it takes is the hosting provider to provide another IP which does not resolve, or, if you aren't as paranoid, just create a server certificate for the IP and not the name (or create for both if you don't care, or 2 with different IPs if you care) - PS: there's currently no PTR from the IP to dailydiapers.com. If you are extra paranoid, you can migrate to a new IP that has never been crawled with association to the name 6) addressing previous issues: "SSL does not help with stopping someone seeing who you are talking with (anonymity)" __no one can prevent this unless you have a federated hosting provider, which could also be vulnerable to volunteer distribution or concentrated data leakage. VPN does not prevent this, just changes the source location to the VPN provider (which could have a universal source IP, but they would still know)__, "validating your permission to do something (authorisation) __this is handled within the web server, not TLS, unless you use client certificates, but that would weaken the anonymity case__ "or non-repudiation (stopping someone from denying they did something - i.e. being able to prove someone did it)" __if no one else can see the traffic (assuming hosting provider of web server does not release or have it compromised), and data is opaque in transmission, and host machine/network is not compromised, how could someone know what is happening? Client certificates are not being used. Source IPs can be shared. All they know is metadata (Source/destination IPs/ports, flags, packet sizes, etc.) Maybe I'm missing something__. 7) MAC address can be changed and do not leave the LAN (private if using a home router, known only to ISP if not) 8) securing the database is another issue separate from TLS. Adding strong cryptographic hashing with salt would help that (and not having the database vulnerable to leakage, too, probably). Anything that makes it difficult to reverse in a reasonable amount of time would, too (in addition to salted strong hash). Also, constant updates to software, security audits, log monitoring, etc. 9) another side note: HTTP Strict Transport Security Anyway, good enough for now. Hope it helps...
×
×
  • Create New...