View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001091 | HTML & PERL | Feature Request - Interface | public | 2008-04-13 10:32 | 2008-06-03 12:28 |
| Reporter | organom | Assigned To | exp | ||
| Priority | normal | Severity | trivial | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001091: Https support | ||||
| Description | Needed ssl encryption on the website (https). If not in all the website (may get the server a bit slow) at least in the log in process. This will at least give a small and decent layer of security to protect the users passwords when accessing in public places. | ||||
| Tags | encryption | ||||
|
|
Well, I am probably one of the last people on this planet who would argue against encryption. However, it really depends on your threat model. The only area where SSL would provide real security benefits which can't be obtained by other means is against attackers somewhere within the backbone of your ISP or the ISP which hosts AniDB. A "public place" doesn't become secure by simply applying an SSL encryption layer. I.e. SSL is pointless in an internet cafe, as you can't trust the PCs. Another bad example are wireless LANs, SSL encryption is the wrong approach here. Instead you should use a VPN tunnel for all your traffic. SSL doesn't hurt of course, but it increases the server load which is problematic for a non-profit page like AniDB. And it is pointless unless you encrypt _all_ pages (cookie sniffing) (all those pages out there which only use SSL during login really deserve a good beating). Maybe we'll offer SSL encryption someday, but probably not by default. You'd have to explicitly use https and it would then be used for all pages. On another note. If you're mainly concerned about your password being transfered in plain text and not about session cookie sniffing (which is about as much security as you get from an SSL "protected" login form) you could use the "remember" option when logging in. That way your password will only be transfered once and from there on only a special autologin hash is used (everyone who gets his hands on that hash could of course still impersonate you on AniDB). |
|
|
Although i agree with you in most of the points, i must express another aspect that misses. My worry is without doubt the clean text password transfer. Since i use my laptop in public open wireless channels. I could off course use a VPN tunnel, and although some recent successful developments in MiTM attacks to this kind of tunnels, its still indeed the most secure one. The problem is finding a trustful VPN, since the traffic is only encrypted between the 2 points. After that, if the VPN endpoint is not trustful everything comes to the same point. Ssl protected login is indeed based on a session id, same as cookie login of course, the only difference, without counting that your password no longer goes on clear text, is that the session only lasts while you're connected, that is completely different from the cookie login. If they catch one's cookie you can log in endlessly while the user don't force logout and renew the cookie. In the other hand if you catch a ssl session id, you'll only be able to use it while the user is connected, and although i don't know the entire ssl parameters, especially applied to the web server, i'm hopping that they block the same session id using multiple ips simultaneously. I understand really well that, especially in a server like anidb, full encryption is like killing the server, and so i was only asking for ssl in the login and as optional would be fair enough. Thanks for all the good work ^_^ |
|
|
So why don't you remain logged in then? If you use the "remember" option at home once, your password will no longer be transfered when you access anidb somewhere else. Btw. using an open wireless LAN without VPN is just asking for trouble. You could rent your own virtual private server somewhere and use that as the end point for your VPN. An Amazon EC2 on-demand server might also do the trick. I see absolutely no point in offering SSL for the login only. That is just stupid and provides our users with a false sense of security. If we offer SSL encryption, it has to apply to all pages and would therefore not be enabled by default for performance reasons. |
|
|
Since, "(...) If they catch one's cookie you can log in endlessly while the user don't force logout and renew the cookie. (...)", and for the reason i'm 3700 km's away from home for the next 4 months. :P VPN for pay would be a nice thing indeed, but... it costs money ^_^ If its your final decision off course, as user, i have to accept it and try to find another way to go around ^_^ Thanks for everything and sorry for all the trouble. |
|
|
I am not saying we won't do it. In fact I'd like to offer SSL encryption, but I've been reluctant to add it so far due to the increased maintenance effort required. Also note: 1) we'd only have a self-signed certificate (a certificate would cost us 30$/year per subdomain) 2) it would probably not be advertised/linked anywhere on the main site 3) it would only cover the main site, additional anidb pages like forum, tracker, wiki, sigserver, ... would not be "affected" by the introduction of SSL on the main server. |
|
|
you could also offer an option to send the password as an md5 hash to the server (javascript would hash the password, i have a lib for that) still not secure but at least it would reduce the types of spoofing that could be applied. and for the really paranoid a random virtual keyboard for password typing plus md5 encryption on client side. |
|
|
Both approaches, SSL encryption of the login form and client side hashing of the password prior to transfer are pretty bad alternatives to full SSL encryption. Both would still allow 3rd parties to impersonate you. The only thing which is protected there is the plain text password. And that really isn't anything worth protecting on its own. You're not reusing your AniDB password for other sites, are you? In that sense the plain text password is pretty much equal to it's md5 hash when captured by an attacker. Btw. to get this discussion somewhere, lets just say that I will definitely add full SSL support at some point but haven't decided on the exact time frame yet. Maybe we could combine that with a move to Apache 2. |
|
|
Ok, we now have SSL support for the main server. URL: https://anidb.net ROOT CA: http://static.anidb.net/misc/ca.crt SHA1 Fingerprint=42:B5:D9:B7:2A:AC:18:5F:A7:10:4C:66:A6:B2:3A:E4:3C:EF:FC:D6 Please note: All requests for images, stylesheets and other page elements are NOT encrypted. Such requests should usually not be directed towards "anidb.net" but rather towards specific subdomains (i.e. "static.anidb.net" or "imgX.anidb.net"). Requests to subdomains do not include the anidb authentication cookies and should thus not allow attackers to hijack your anidb session. This means that: a) If we've accidentially hardcoded an access to http://anidb.net somewhere, this would instantly allow an attacker to obtain your session authorisation cookie. b) Attackers may be able to infer the anidb pages you're browsing on and your anidb user id by looking at the cookie and referer data sent to anidb subdomains when stylesheet and image data is loaded. For maximum security you should browse anidb with all images and stylesheets disabled. Or, the recommended approach, use some VPN. |
|
|
Due to a potentially weak random number generator the certificates had to be replaced. https://anidb.net fingerprint SHA1 Fingerprint=4C:2E:A6:D2:39:29:90:C4:0A:47:ED:7B:C4:DB:14:90:7D:EE:36:50 ca.anidb.net fingerprint SHA1 Fingerprint=BE:BB:3D:9D:5D:77:FE:AB:77:89:F5:37:57:DB:82:AA:C3:3A:CF:CA new root ca cert available under: http://static.anidb.net/misc/ca.crt |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-04-13 10:32 | organom | New Issue | |
| 2008-04-13 18:12 | exp | Note Added: 0001954 | |
| 2008-04-14 13:24 | organom | Note Added: 0001957 | |
| 2008-04-14 19:47 | exp | Note Added: 0001958 | |
| 2008-04-15 09:21 | organom | Note Added: 0001959 | |
| 2008-04-15 11:37 | exp | Note Added: 0001960 | |
| 2008-04-17 00:23 | fahrenheit | Note Added: 0001969 | |
| 2008-04-17 09:11 | exp | Note Added: 0001971 | |
| 2008-04-17 09:11 | exp | Status | new => assigned |
| 2008-04-17 09:11 | exp | Assigned To | => exp |
| 2008-04-17 21:43 | exp | Note Added: 0001973 | |
| 2008-04-17 21:44 | exp | Status | assigned => resolved |
| 2008-04-17 21:44 | exp | Resolution | open => fixed |
| 2008-04-19 00:02 | ninjamask | Tag Attached: encryption | |
| 2008-06-03 12:28 | exp | Note Added: 0002130 |
