![]() ![]() ![]() if the https becomes red or crossed out, it's not your server you are talking to, so do not send credentials Get used to not ignoring SSL warning: Your server(s) have to show a green (in Chrome) or grey (in Firefox) "https" at the beginning of the URL, indicating that the browser trusts the server, which is due to the fact that it trusts your freshly installed CA root.Feed your newly created, personal server cert(s) to OpenWebif (/etc/enigma2/key.pem and /etc/enigma2/cert.pem) and oscam /etc/tuxbox/config/oscam/oscam.pem (joined key.pem+cert.pem) and add /etc/tuxbox/config/oscam/oscam.pem to your nf, enable SSL in oscam.Add your personal "CA root" certificate to the repo of trusted root authorities on all your client device(s).Create server keys and certs signed by this CA root for OpenWebif, oscam, vsftpd.Become your own CA root (Certificate root authority) using OpenSSL.Once the VPN is up and running, you should be able to use anything on the box like you would in your home LAN.using your router's VPN functionality (if present) or directly between the external point of access and the E2 box itself, e.g. Establish a VPN, either between your external point of access and your home network, e.g.This is as of now the most secure way to acess the box, but also the most inconvenient when it comes to the web interface and so on due to the ssh tunnel setup (Rather easy to set up on a PC, but ugly on a Smartphone, Tablet, whatever, where you more likely need remote access).Use ssh directly for console access, sftp (ftp over ssh) for file access and tunnel everything else as needed through ssh (There are enough existing tutorials that explain ssh-tunneling, no need to repeat those here).Open only the port for ssh to the outside.Install the OpenSSH-sftp-Server component.Configure ssh for key auth (rather than login/pass). ![]() Is there a simple tutorial for newbies you would recommend in order to have a good level of protection ?Nope. No heartbeat response received, server likely not vulnerable Unexpected EOF receiving record header - server closed connection received message: type = 22, ver = 0302, length = 4 received message: type = 22, ver = 0302, length = 482 received message: type = 22, ver = 0302, length = 58 Options: bn(64,32) rc4(idx,int) des(idx,risc2,16,long) idea(int) blowfish(idx)Ĭompiler: mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float -march=mips32 -sysroot=/dreambox/oe.openpli-4/build/tmp/sysroots/vuultimo -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Os -pipe -g -feliminate-unused-debug-types -Wall -Wa,-noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS +CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_HEARTBEATS" CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS" So yes, a simple switch fixes the vulnerability. TLS server extension "heartbeat" (id=15), len=1 TLS server extension "session ticket" (id=35), len=0 ![]() TLS server extension "renegotiation info" (id=65281), len=1 Openssl s_client -connect ultimo:443 -tlsextdebug > heartbeat The only problem being the patches applied to OpenSSL 1.0.1e before building about which I do not know what they are good for or in other words: If they are still required/useful with OpenSSL 1.0.1g. Do you have a ready patch then?In theory, yes. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |