Topic: GLBSE back up and market open. (Read 4236 times)
Markets back up.
Money isn't the problem. The problem is I'm currently based in China.
I've been unable to get a signed cert so far, and I'm not getting one from the Chinese cert auth (that's even more difficult and also insecure).
Also with regards security of self signed certs, it comes down to a question of who do you trust, me or verisign.
http://webdesign.about.com/od/ssl/a/signed_v_selfsi.htm
The only issue is the warning that browsers pop up, makes people uncomfortable.
No, it does not come to a matter of trust between you or verisign. It's a matter of trust between anyone with access to your server, man-in-the middle, and/or verisign. A third party mitigates a man in the middle trust issue. The site you link to makes plenty of arguments for why you should be using a third party signed cert for your production environment.I've been unable to get a signed cert so far, and I'm not getting one from the Chinese cert auth (that's even more difficult and also insecure).
Also with regards security of self signed certs, it comes down to a question of who do you trust, me or verisign.
http://webdesign.about.com/od/ssl/a/signed_v_selfsi.htm
The only issue is the warning that browsers pop up, makes people uncomfortable.
Self-signed certs are more vulnerable to MITM because a user has no way to verify whether the original certificate or certificate changes are legitimate. A diligent user might be able to tell the difference with the use of other information but an average user will not. A third party will verify certificate changes for you, which makes MITM less likely to be a user "error" in trust. It doesn't fully "solve" anything other than user error (unless they are trained to expect self-signed certs from your site), but it is a must have for a service such as yours.
I don't know how much you looked around, but you can get very basic 1 year SSL certs for free at startssl.com. It's a low assurance cert, but it would be sufficient until GLBSE becomes more important.
Money isn't the problem. The problem is I'm currently based in China.
I've been unable to get a signed cert so far, and I'm not getting one from the Chinese cert auth (that's even more difficult and also insecure).
Also with regards security of self signed certs, it comes down to a question of who do you trust, me or verisign.
http://webdesign.about.com/od/ssl/a/signed_v_selfsi.htm
The only issue is the warning that browsers pop up, makes people uncomfortable.
I've been unable to get a signed cert so far, and I'm not getting one from the Chinese cert auth (that's even more difficult and also insecure).
Also with regards security of self signed certs, it comes down to a question of who do you trust, me or verisign.
http://webdesign.about.com/od/ssl/a/signed_v_selfsi.htm
The only issue is the warning that browsers pop up, makes people uncomfortable.
Yeah I dont know how many people I hear that fomr that glbse is in secure just because the certificate is not signed or they think its malicious
And it gives people the notion that you might have recently been hacked... the whole point of secure certificates is that if someone is running a man-in-the-middle attack then your browser should alert you. How do I know your site isn't compromised as we speak? It very well could be.
Can you use a correctly signed certificate assigned by a reputable company and not a self signed one please?
Market is down for the next 12 hours.
Voting has been fixed and is up and running.
Nefario.
Nefario.
Some of the chart subpages (Trade History/Market depth) seem to still be broken, also the database below the charts still don't seem to include all transactions since the start of GLBSE. I guess this has low priority but I still wanted to report it. Keep up the great work! 
charts had the readings backwards for a week or two, and has recorded that information. Thats what's being seen.
Some of the chart subpages (Trade History/Market depth) seem to still be broken, also the database below the charts still don't seem to include all transactions since the start of GLBSE. I guess this has low priority but I still wanted to report it. Keep up the great work!
Web client has been updated.
Issues caused by the release last week have been fixed.
Issues caused by the release last week have been fixed.
Update of the webclient is now live, now it allows you to securely keep the keys for multiple accounts stored on your local machine in the browser.
https://glbse.com/client/glbse/index.html
The old client is available here if you prefer.
https://glbse.com/client/glbse_old/index.html
If there are any issues post them in any one of these threads, I'm watching them.
http://forum.bitcoin.org/index.php?topic=13055.80
http://forum.bitcoin.org/index.php?topic=19853.0
I appologise to anyone who didn't get your issues fixed in a timely manner over the last week, that is totally my fault.
Currently I'm the only one who is in a possition to resolve those issues, and was traveling for a few days. This is something We're hoping to resolve as we go forward.
Nefario.
https://glbse.com/client/glbse/index.html
The old client is available here if you prefer.
https://glbse.com/client/glbse_old/index.html
If there are any issues post them in any one of these threads, I'm watching them.
http://forum.bitcoin.org/index.php?topic=13055.80
http://forum.bitcoin.org/index.php?topic=19853.0
I appologise to anyone who didn't get your issues fixed in a timely manner over the last week, that is totally my fault.
Currently I'm the only one who is in a possition to resolve those issues, and was traveling for a few days. This is something We're hoping to resolve as we go forward.
Nefario.
Updated (on the Vmware image) and get this error:
Server error: server certificate verification failed. CAfile: server.crt CRLfile: none
Server error: server certificate verification failed. CAfile: server.crt CRLfile: none
took a look around GLBSE ... interesting project you are developing there... when will GLBSE be listed on the GLBSE, I could buy some shares of that?
We're not selling ATM, I guess when we need funding then it will happen the, but we will be putting some other projects up.
Nefario.
took a look around GLBSE ... interesting project you are developing there... when will GLBSE be listed on the GLBSE, I could buy some shares of that?
GLBSE is back up and open for business.
In answer to your comments TheVirus,
We will be getting a CA signed certificate, it's not the top priority ATM(Also using self signed cert prevent's our traffic being sniffed if a CA is compromised, I wonder how big a worry this is for actual GLBSE users though).
I'm not sure what the testing was actually, this was cuddlefish's doing (cuddlefish, could you fill us in).
No IDS yet.
I do keep a secure backup of the wallet offline.
The wallet on system has full funds ATM, this is because we're still using bitcoind's accounts (along with our own) to ensure we've got two sets of books so we can see where any problems arise when there's a difference.
DB is on the same server as webserver, however the DB has no identifying information or passwords, just a list of public keys. Not even emails. We try to keep identifying information we keep to an absolute min.
Also the server is chrooted with non root process permissions.
We have logs (of course) but no active monitoring system(bar myself). We also keep records of ip's, and use denyhosts.
We have no limits on transfer or trading once it's authorised by the user.
To be able to steal from a single users account (as opposed to breaking into the actual system) would require the attacker to get ahold of the users private key on their home machine. Once they have this there is no way to prove that they are not indeed the user. The private key is the users only proof of ownership of the account.
Unless we begin recording identifying information there is nothing we can do if the private key is compromised.
We do of course also disable root access for ssh, have long and unique passwords for each user on the system, and have a strictish firewall policy.
The security setup is going to change as time goes on bringing improvements.
On our list of security todo:
Have the DB on a separate machine of the app server.
Have fractional reserves kept in the system wallet (with the rest stored securly offline).
Have an intrusion detection system.
Begin using SELinux.
Active log monitoring.
Any idea's for improving security is much appreciated(low hanging fruit preferable).
Nefario.
In answer to your comments TheVirus,
We will be getting a CA signed certificate, it's not the top priority ATM(Also using self signed cert prevent's our traffic being sniffed if a CA is compromised, I wonder how big a worry this is for actual GLBSE users though).
I'm not sure what the testing was actually, this was cuddlefish's doing (cuddlefish, could you fill us in).
No IDS yet.
I do keep a secure backup of the wallet offline.
The wallet on system has full funds ATM, this is because we're still using bitcoind's accounts (along with our own) to ensure we've got two sets of books so we can see where any problems arise when there's a difference.
DB is on the same server as webserver, however the DB has no identifying information or passwords, just a list of public keys. Not even emails. We try to keep identifying information we keep to an absolute min.
Also the server is chrooted with non root process permissions.
We have logs (of course) but no active monitoring system(bar myself). We also keep records of ip's, and use denyhosts.
We have no limits on transfer or trading once it's authorised by the user.
To be able to steal from a single users account (as opposed to breaking into the actual system) would require the attacker to get ahold of the users private key on their home machine. Once they have this there is no way to prove that they are not indeed the user. The private key is the users only proof of ownership of the account.
Unless we begin recording identifying information there is nothing we can do if the private key is compromised.
We do of course also disable root access for ssh, have long and unique passwords for each user on the system, and have a strictish firewall policy.
The security setup is going to change as time goes on bringing improvements.
On our list of security todo:
Have the DB on a separate machine of the app server.
Have fractional reserves kept in the system wallet (with the rest stored securly offline).
Have an intrusion detection system.
Begin using SELinux.
Active log monitoring.
Any idea's for improving security is much appreciated(low hanging fruit preferable).
Nefario.
I've run a Nessus scan and poked around a bit with Metasploit. The key auth (instead of password) does excellent things for the actual app's security.
The only thing I've noticed is a lack of syn cookies, which if enabled would prevent a certain type of DoS.
GLBSE is back up and open for business.
In answer to your comments TheVirus,
We will be getting a CA signed certificate, it's not the top priority ATM(Also using self signed cert prevent's our traffic being sniffed if a CA is compromised, I wonder how big a worry this is for actual GLBSE users though).
I'm not sure what the testing was actually, this was cuddlefish's doing (cuddlefish, could you fill us in).
No IDS yet.
I do keep a secure backup of the wallet offline.
The wallet on system has full funds ATM, this is because we're still using bitcoind's accounts (along with our own) to ensure we've got two sets of books so we can see where any problems arise when there's a difference.
DB is on the same server as webserver, however the DB has no identifying information or passwords, just a list of public keys. Not even emails. We try to keep identifying information we keep to an absolute min.
Also the server is chrooted with non root process permissions.
We have logs (of course) but no active monitoring system(bar myself). We also keep records of ip's, and use denyhosts.
We have no limits on transfer or trading once it's authorised by the user.
To be able to steal from a single users account (as opposed to breaking into the actual system) would require the attacker to get ahold of the users private key on their home machine. Once they have this there is no way to prove that they are not indeed the user. The private key is the users only proof of ownership of the account.
Unless we begin recording identifying information there is nothing we can do if the private key is compromised.
We do of course also disable root access for ssh, have long and unique passwords for each user on the system, and have a strictish firewall policy.
The security setup is going to change as time goes on bringing improvements.
On our list of security todo:
Have the DB on a separate machine of the app server.
Have fractional reserves kept in the system wallet (with the rest stored securly offline).
Have an intrusion detection system.
Begin using SELinux.
Active log monitoring.
Any idea's for improving security is much appreciated(low hanging fruit preferable).
Nefario.
In answer to your comments TheVirus,
We will be getting a CA signed certificate, it's not the top priority ATM(Also using self signed cert prevent's our traffic being sniffed if a CA is compromised, I wonder how big a worry this is for actual GLBSE users though).
I'm not sure what the testing was actually, this was cuddlefish's doing (cuddlefish, could you fill us in).
No IDS yet.
I do keep a secure backup of the wallet offline.
The wallet on system has full funds ATM, this is because we're still using bitcoind's accounts (along with our own) to ensure we've got two sets of books so we can see where any problems arise when there's a difference.
DB is on the same server as webserver, however the DB has no identifying information or passwords, just a list of public keys. Not even emails. We try to keep identifying information we keep to an absolute min.
Also the server is chrooted with non root process permissions.
We have logs (of course) but no active monitoring system(bar myself). We also keep records of ip's, and use denyhosts.
We have no limits on transfer or trading once it's authorised by the user.
To be able to steal from a single users account (as opposed to breaking into the actual system) would require the attacker to get ahold of the users private key on their home machine. Once they have this there is no way to prove that they are not indeed the user. The private key is the users only proof of ownership of the account.
Unless we begin recording identifying information there is nothing we can do if the private key is compromised.
We do of course also disable root access for ssh, have long and unique passwords for each user on the system, and have a strictish firewall policy.
The security setup is going to change as time goes on bringing improvements.
On our list of security todo:
Have the DB on a separate machine of the app server.
Have fractional reserves kept in the system wallet (with the rest stored securly offline).
Have an intrusion detection system.
Begin using SELinux.
Active log monitoring.
Any idea's for improving security is much appreciated(low hanging fruit preferable).
Nefario.
Just to let people know, don't use GLBSE just yet, running tests at the moment to ensure all is working as it should.
We're almost ready to launch, however our servers are having some network trouble, and as a result glbse.com is down.
I've had cuddlefish do some poking and penetration testing on the servers and so far no obvious holes.
Everything is over SSL now, all traffic to glbse.com will be redirected to https.
The certificate is self signed (so on first visiting it will pop up a warning).
This now means that you can use the keypair generation on the server (built into the web client) without the worry of it being sniffed.
A few of the URL's have changed a little, and once we get our networking issues sorted out we'll update them.
The web client is available at https://glbse.com/client/glbse/
We have also update the command line client so that it's able to operate over SSL, to be able to use the command line client please use git to update the files.
If you're not on git(Windows user?) please download these two files into the black-market directory.
https://gitorious.org/black-market/black-market-client/blobs/raw/master/server.crt
https://gitorious.org/black-market/black-market-client/blobs/raw/master/bmc.py
From then on everything should be the same, with the exception that everything to the server is encrypted.
Nefario.
I've had cuddlefish do some poking and penetration testing on the servers and so far no obvious holes.
Everything is over SSL now, all traffic to glbse.com will be redirected to https.
The certificate is self signed (so on first visiting it will pop up a warning).
This now means that you can use the keypair generation on the server (built into the web client) without the worry of it being sniffed.
A few of the URL's have changed a little, and once we get our networking issues sorted out we'll update them.
The web client is available at https://glbse.com/client/glbse/
We have also update the command line client so that it's able to operate over SSL, to be able to use the command line client please use git to update the files.
If you're not on git(Windows user?) please download these two files into the black-market directory.
https://gitorious.org/black-market/black-market-client/blobs/raw/master/server.crt
https://gitorious.org/black-market/black-market-client/blobs/raw/master/bmc.py
From then on everything should be the same, with the exception that everything to the server is encrypted.
Nefario.
You can get a CA generated SSL cert from many places (www.networksolutions.com, www.godaddy.com) for a few hundred dollars. I highly recommend this as it will prevent your site from being flagged by Google/Chrome as being malicious. Also, what kind of pen testing did you do? Did you use a Nessus scan or MetaSploit stuff? Do you have any IDS/IPS software installed? Do you have a secured wallet stored offline? I think banks are required to keep 10% of their deposits in-house, so it might be wise to follow a similar protocol.
Are you running multiple servers, one for DB and one for web? Are you actively monitoring all access logs? Do you have anything in place that will send out alerts should something fishy happen (such as someone selling 500k BTC at once)? I'd want to make very large trades moderated. Are you tracking IPs to try and check for suspicious activity (much like Gmail does), so if I have an IP that originates from San Fran, CA, and then log in from South Korea, it should deny all write/execute access to the account until it's verified. It'd be nice to see a simplified version of how the data is protected and what security checks are in place (no need to get into the specific software/services used, just what they do).
We're up and open.
I've had cuddlefish do some poking and penetration testing on the servers and so far no obvious holes.
Everything is over SSL now, all traffic to glbse.com will be redirected to https.
The certificate is self signed (so on first visiting it will pop up a warning).
This now means that you can use the keypair generation on the server (built into the web client) without the worry of it being sniffed.
A few of the URL's have changed a little, and once we get our networking issues sorted out we'll update them.
The web client is available at https://glbse.com/client/glbse/
We have also update the command line client so that it's able to operate over SSL, to be able to use the command line client please use git to update the files.
If you're not on git(Windows user?) please download these two files into the black-market directory.
https://gitorious.org/black-market/black-market-client/blobs/raw/master/server.crt
https://gitorious.org/black-market/black-market-client/blobs/raw/master/bmc.py
From then on everything should be the same, with the exception that everything to the server is encrypted.
Nefario.
I've had cuddlefish do some poking and penetration testing on the servers and so far no obvious holes.
Everything is over SSL now, all traffic to glbse.com will be redirected to https.
The certificate is self signed (so on first visiting it will pop up a warning).
This now means that you can use the keypair generation on the server (built into the web client) without the worry of it being sniffed.
A few of the URL's have changed a little, and once we get our networking issues sorted out we'll update them.
The web client is available at https://glbse.com/client/glbse/
We have also update the command line client so that it's able to operate over SSL, to be able to use the command line client please use git to update the files.
If you're not on git(Windows user?) please download these two files into the black-market directory.
https://gitorious.org/black-market/black-market-client/blobs/raw/master/server.crt
https://gitorious.org/black-market/black-market-client/blobs/raw/master/bmc.py
From then on everything should be the same, with the exception that everything to the server is encrypted.
Nefario.
Jump to: