From 11972a5364c4c39a46b0e9875c698d2ff21dd93b Mon Sep 17 00:00:00 2001 From: Refik Hadzialic Date: Sat, 8 Oct 2011 22:06:38 +0200 Subject: Just wrote the part on creating the certificate for SSL. --- notFinishedCode/Report/test.tex.backup | 120 ++++++++++++++++++++++++++++++++- 1 file changed, 117 insertions(+), 3 deletions(-) (limited to 'notFinishedCode/Report/test.tex.backup') diff --git a/notFinishedCode/Report/test.tex.backup b/notFinishedCode/Report/test.tex.backup index 6f41bb3..b54cbe6 100644 --- a/notFinishedCode/Report/test.tex.backup +++ b/notFinishedCode/Report/test.tex.backup @@ -104,6 +104,8 @@ Gradually we implemented a bit-by-bit of the final software. Every single step w \newpage \section{Software concept} % chapter 2 \newpage +\section{Database design} +\newpage \section{Introduction} % section 2.1 \subsection{Usage} % subsection 2.1.1 \newpage @@ -135,7 +137,7 @@ Gradually we implemented a bit-by-bit of the final software. Every single step w \end{figure} %\newpage -\section{Security and safety of the test system} +\section{Security and safety of the system} \large Safety and security of the software plays a major role in our project. It is of vital importance that only as few as possible people have access to our test system since the resulting data could be exploited to plan an attack (e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment.) Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works. @@ -197,11 +199,120 @@ The test was successful. We tested it with our SSH Tunnel port forwarding class \subsection{Security on the web site} Securing the communication channels without making certain the web site is safe would be worthless. We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle -could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected WiFi network). +could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected wireless network) \cite{https}. At the same time the web site should be accessible only by the authorized personel. Our first approach to this problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Denis to use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using -these two techniques we protected the web site of some vulnerabilities known to us. +these two techniques we protected the web site of some vulnerabilities known to us. If the web site +will be only accessed from our local university network, we can additionally add an IP filter mask as well. +In the following paragraph we will explain our procedure how to generate the keys and to enable the https protocol. +\par First we want to generate a server key by typing the following command: +\begin{lstlisting} +openssl genrsa -des3 -out server.key 4096 +\end{lstlisting} +\par This will generate a 4096 bit long private server key, one is asked to enter two times a password for the \emph{server.key}. +Using the generated private server key, we will create a certificate signing request, \emph{server.csr}. We were prompted with a series of questions +like country, state, organization name and etc which we had to enter to resume. +\begin{lstlisting} +openssl req -new -key server.key -out server.csr +\end{lstlisting} +\par In the next step we had to sign the certificate signing request and enter the amount of days for how long it should be valid. +In our case we entered the duration of one year, one can make it for longer periods as well (i.e. the amount of 365 has to be changed.) +\begin{lstlisting} +openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt +\end{lstlisting} +\par We were asked to enter the password again for \emph{server.key}. After we have completed this step we had to make +a version of the \emph{server.key} which did not require a password, \emph{server.key.insecure} and we will rename the files appropriately. +\begin{lstlisting} +openssl rsa -in server.key -out server.key.insecure +mv server.key server.key.secure +mv server.key.insecure server.key +\end{lstlisting} +\par The generated files are very sensitive, since they are our keys. After these steps were completed, we had generated 4 files (\emph{server.crt}, \emph{server.csr}, \emph{server.key} and \emph{server.key.secure}). Now we need to enable the SSL engine on the Apache web server. +We coppied \emph{server.key} and \emph{server.crt} into \emph{/etc/appache2/ssl}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2$ sudo mkdir ssl +cp server.key /etc/apache2/ssl +cp server.crt /etc/apache2/ssl +\end{lstlisting} +Then we enabled SSL by typing in \emph{a2enmod ssl}, ``it is simply a general purpose utility to establish a symlink between a module in \emph{/etc/apache2/mods-available} to \emph{/etc/apache2/mods-enabled} (or give a message to the effect that a given module does not exist or that it is already symlinked for loading)'' \cite{https}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo a2enmod ssl +Enabling module ssl. +See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. +Run '/etc/init.d/apache2 restart' to activate new configuration! +\end{lstlisting} +\par In the next procedure we had to establish a symlink from the 'available' default-ssl file to the 'enabled' file \cite{https}. Then we created a folder where our secured PHP files will be located (e.g. https://some-domain-name.com/test-software). +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl +refik@ubuntu:/etc/apache2/ssl$ cd /var/ +refik@ubuntu:/var$ sudo mkdir www-ssl +\end{lstlisting} +\par We had backed up our old configuration files for the virtual hosts, for the case that the damage the Apache configuration files. Then we edited the \emph{default-ssl} file. +\begin{lstlisting} +refik@ubuntu:/var$ cd /etc/apache2/sites-available +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default default_original +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default-ssl default-ssl_original +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par Only the begining of the file is listed here and we have modified the line starting with \emph{DocumentRoot} +from \emph{DocumentRoot /var/www} to \emph{DocumentRoot /var/www-ssl} (i.e. we had to redefine the location of our SSL directory.) +\begin{lstlisting} + + + ServerAdmin webmaster@localhost + + DocumentRoot /var/www-ssl + + Options FollowSymLinks + AllowOverride None + +\end{lstlisting} +\par One should keep in mind that the port 443 should be free for Apache to use it. In the proceeding step we had to ensure that Apache listens on the given port for a \emph{https} connection. +One could test that by going into the \emph{/etc/apache2/ports.conf}. +\begin{lstlisting} + + # If you add NameVirtualHost *:443 here, you will also have to change + # the VirtualHost statement in /etc/apache2/sites-available/default-ssl + # to + # Server Name Indication for SSL named virtual hosts is currently not + # supported by MSIE on Windows XP. + Listen 443 + +\end{lstlisting} +\par In our case it was set up correctly, since the command: \emph{Listen 443} was present. +In our last configuration step we had to edit \emph{default-ssl} file to define the correct locations of our keys and to ensure the SSL engine was turned on. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\newpage +\par The following part had to be found and modified according to our locations: +\begin{lstlisting} +SSLEngine on + + # A self-signed (snakeoil) certificate can be created by installing + # the ssl-cert package. See + # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. + # If both key and certificate are stored in the same file, only the + # SSLCertificateFile directive is needed. + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + # Server Certificate Chain: + # Point SSLCertificateChainFile at a file containing the +\end{lstlisting} +Finally we had configured our server and can proceed with the restart of the apache web server. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo /etc/init.d/apache2 restart + * Restarting web server apache2 [Sat Oct 08 21:52:51 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence + ... waiting [Sat Oct 08 21:52:52 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence [ OK ] +refik@ubuntu:/etc/apache2/sites-available$ +\end{lstlisting} + + + + + \newpage \section{Web page} @@ -225,6 +336,9 @@ Hypothesis}, preprint (2003), available at \bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at \url{http://goo.gl/fX68N}. +\bibitem{https} P. Bramscher, \emph{Creating Certificate Authorities and self-signed SSL certificates}, accessed on 05.09.2011, available at +\url{http://www.tc.umn.edu/~brams006/selfsign.html}. + %bibliography end \end{thebibliography} -- cgit v1.2.3-55-g7522