Trabalho elaborado por:                        Ricardo Nuno Mendão da Silva    rnsilva@student.dei.uc.pt                   Jorge Miguel Morgado Henriques  jmmh@student.dei.uc.pt   

 

 

 

ContentsContents ........................................................................................................................................ 2 

1.  Introdução............................................................................................................................. 4 

2.  Objectivos.............................................................................................................................. 5 

3.  Activação da CA privada........................................................................................................ 5 

3.1.  Criação da chave de encriptação .................................................................................. 5 

3.2.  Criação do Certificate Signing Request  (CSR) ............................................................... 6 

3.3.  Criação do Certificado “self signed”.............................................................................. 6 

4.  Obtenção de certificados x509.............................................................................................. 7 

4.1.  Criação da chave de encriptação .................................................................................. 8 

4.2.  Criação do Certificate Signing Request  (CSR) ............................................................... 9 

4.3.  Criação do Certificado ................................................................................................... 9 

5.  Ficheiros de configuração ................................................................................................... 10 

5.1.  openssl.conf ................................................................................................................ 10 

5.2.  httpd.conf.................................................................................................................... 12 

5.3.  ssl.conf......................................................................................................................... 13 

6.  Testes .................................................................................................................................. 17 

6.1.  Área ssc05.dei.uc.pt .................................................................................................... 17 

1.1.1.  6.1.1. Acesso válido. ............................................................................................ 17 

6.1.2.  Acesso de cliente sem autorização ou fora de tempo ........................................ 19 

6.1.3. Acesso sem certificado.............................................................................................. 22 

6.2.  Área sec05.dei.uc.pt.................................................................................................... 23 

6.2.1.  Acesso com certificado emitido pela CA privada ................................................ 23 

6.3.  Área intra05.dei.uc.pt ................................................................................................. 26 

6.3.1.  Acesso a partir da rede 10.254.0.0/24 ................................................................ 26 

6.3.2.  Acesso com login e password.............................................................................. 26 

6.4.  Acesso com certificado revogado ............................................................................... 28 

7.  Funcionalidades não implementadas ................................................................................. 30 

8.  Conclusão ............................................................................................................................ 31 

9.  Bibliografia .......................................................................................................................... 32 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Introdução  

  Com o desenvolvimento dos meios de comunicação,   observa‐se uma convergência do uso destes, por parte de vários sectores sócio‐económicos, exigindo cada vez mais a garantia de um bom serviço, ou seja,  fiável, eficaz e sobretudo  seguro, permitindo que o utilizador  final possa  efectuar  operações  delicadas,  por  exemplo  transacções  financeiras,  sem  que  corra  o risco dessas transacções serem interceptadas por terceiros, tendo ainda a garantia de que está a  efectuar  a  transacção  com  a  entidade  pretendida.  Assim,  foi  desenvolvido  o  protocolo criptográfico SSL (Secure Sockets Layer) que permite garantir a privacidade e  integridade dos dados, trocados entre duas entidades. Normalmente o ssl penas utiliza certificação do lado do servidor  , garantindo assim ao utilizador que está  ligado à entidade  correcta,  contudo pode também utilizar  autenticação do  lado do utilizador,  fazendo  com que este necessite de um certificado    de  autenticação,  que  pode  ser  fornecido  por  uma  Autoridade  de  certificação conhecida, ou por uma Autoridade privada. Para a criação de uma Autoridade de certificados privada, pode ser usado o OpenSSL que é basicamente uma ferramenta de implementação do protocolo SSL. Com o OpenSSL é possível criar um certificado x509 self signed  , criando então a Autoridade de Certificação privada, que pode funcionar como as Autoridades de Certificação oficiais,  permitindo  criar  certificados  para  os  utilizadores.    O  x509  é  um  standard  que especifica  vários  padrões  dos  vários  componentes  intervenientes  na  comunicação  segura, como por exemplo o formato das chaves e algoritmos.  A Autoridade de Certificação para além de criar os certificados, pode também suspende‐los, ou seja, torna‐los  inválidos antes do seu prazo de validade terminar.  

Todo o processo de acesso seguro, corre obviamente sobre um  servidor web comum, como por  exemplo  o  apache.  Para  implementar  as  funcionalidades  de  segurança  requeridas,  o apache  possuí  um  módulo  chamado,  mod_ssl  ,  que  permite  efectuar  as  mais  variadas configurações  de  restrição  e  requerimento  de  certificados  para  com  os  utilizadores, implementando  assim o  sistema de  acesso  remoto  via  ssl, neste  caso  através do protocolo https. Para além deste sistema de segurança através do mod_ssl  o apache permite um outro modo de segurança, nomeadamente através da autenticação dos utilizadores através de um sistema de username e password,  implementado pelo mod_auth, sendo claramente bastante inferior em segurança e flexibilidade quando comparado com o SSL.  

Neste relatório irá constar um longo processo de descrição e testes das operações efectuadas para  a  criação  de  Autoridades  de  Certificação  privadas,  para  a  criação  de  certificados  a utilizadores  comuns  e  para  a  configuração  de  servidores  de  acesso  seguro,  com  as  mais variadas restrições. 

 

 

 

2. Objectivos  

Pretende‐se  neste  trabalho    utilizar  o  OpenSSL  para  activação  de  uma  Autoridade  de  Certificação  privada,  para  posteriormente  criar  certificados  e  listas  de  revogação  de certificados.  Pretende‐se  ainda  que  seja  efectuada  a  configuração  do  apache  para autenticação  e  autorização  de  acessos  a  zonas  de documentos,  segundo  vários  critérios  de segurança. 

3. Activação da CA privada  

Neste  ponto  irão  ser  descritos  os  passos  necessários  para  a  criação  de  uma Autoridade  de Certificação privada, sendo especificado cada parâmetro utilizado por comando. Cada um dos pontos  seguintes,  corresponde  a  um  passo  para  a  criação  do  certificado  da  Autoridade  de Certificação.  

              Figura 1 – Criação de CA privada 

3.1. Criação da chave de encriptação    

  Neste ponto irá ser descrito o comando utilizado para gerar a chave encriptada. Ver    

Comando  Openssl genrsa –out private/ca.key 1024 

 genrsa  Define o tipo de algoritmo de encriptação para o 

algoritmo RSA, desenvolvido por professores do MIT,  nomeadamente    Ron  Rivest,  Adi  Shamir  e Len Adleman.

‐out private/ca.key  Define  o  ficheiro  resultante  e  guarda‐o  na directoria referida, neste caso na pasta “private”. 

Parâmetros 

1024  Número de bits de encriptação que compõem a chave. 

 

 

3.2. Criação do Certificate Signing Request  (CSR)    

  O CSR é um  ficheiro que  contém  informação   da entidade que  solicita o certificado.     Neste  caso  a  própria  “futura”  Autoridade  privada.  Contém  ainda  a  chave  pública  e   informação  do  servidor  onde  está  instalado.  Não  é  mais  que  um  certificado   desencriptado. 

 

   

 

 

3.3. Criação do Certificado “self signed”   

Por  fim,  já  com o CSR  criado, basta  encriptar  este  com  a  chave da própria  entidade que o “pediu”, sendo a origem do termo “self signed”. 

Comando  openssl x509 -req -days 365 -in ca.csr -out certs/SSC\ CA.crt -signkey private/ca.key  

Parâmetros  X509 É um comando que permite mostrar, converter,

editar ou assinar certificados, sendo este último, o propósito da sua utilização neste caso.

Comando  Openssl req –new –key private/ca.key –out ca.csr  Parâmetros  req  Utilizado para processos de gestão do CSR.   ‐new  Flag que identifica o comando como criação de um 

novo item.    ‐key 

private/ca.key Indica a chave da entidade que solicita o certificado. 

  ‐out ca.csr  Indica onde ficará o ficheiro resultante deste comando.

-req Opção que indica a entrada de um CSR, em vez da opção por defeito do x509 que é um certificado.

-days 365 Indica a validade do certificado. -in ca.csr Indica o CSR a encriptar. -out certs/SSC\ CA.crt

Indica qual o destino e o nome do ficheiro resultante da execução deste comando.

-signkey private/ca.key

Indica a chave que irá encriptar o CSR inserido na opção –in.

 

4. Obtenção de certificados x509  

Neste ponto  irá ser especificado como se processa a obtenção de certificados com o padrão x509  emitidos  pela  Autoridade  de  Certificação  criada  no  ponto  3.  Este  processo  pode  ser comprovado imagem seguinte. 

 

 

Figura 2 – Emissão de certificado para cliente 

Neste trabalho gerou‐se uma chave rsa de 1024 bits para cada certificado emitido. O processo efectuado foi o mesmo que o descrito no ponto 3.1.. Emitiram‐se 4 certificados x509 baseados na  referida  CA,  sendo  que  3  foram  atribuídos  às  três  áreas  de  documentos  pedidas, nomeadamente  https://sec05.dei.uc.pt  https://ssc05.dei.uc.pt  e  https://intra05.dei.uc.pt  . O quarto certificado foi atribuído a um utilizador de teste.  

Os sub‐pontos que se seguem foram idênticos para os 4 certificados emitidos, variando apenas os nomes dos ficheiros resultantes, entre sec05, ssc05 e intra05 respectivamente. 

4.1. Criação da chave de encriptação    

Comando  Openssl genrsa –out private/sec05.key 1024  Parâmetros  genrsa  Define o tipo de algoritmo de encriptação para o 

algoritmo RSA, desenvolvido por professores do MIT,  nomeadamente    Ron  Rivest,  Adi  Shamir  e Len Adleman.

‐out private/sec05.key 

Define  o  ficheiro  resultante  e  guarda‐o  na directoria referida, neste caso na pasta “private”. 

1024  Número de bits de encriptação que compõem a chave. 

 

 

4.2. Criação do Certificate Signing Request  (CSR)  

Neste caso o CSR contém  a informação da entidade “sec05”, sendo que no campo “Common Name” terá de ser introduzido o nome completo da área (FQDN), ou seja, sec05.dei.uc.pt. no caso do CN ser diferente do nome da área, um qualquer utilizador quando aceder a essa área irá receber uma mensagem de notificação, indicando possível tentativa de passagem por falsa identidade. 

   

 

 

4.3. Criação do Certificado       

Por  fim, com o CSR criado, este  terá de  ser encriptado por uma Autoridade de Certificação, que neste caso é a “SSC CA” criada no ponto 3. 

Comando  openssl ca -in sec05.csr -cert certs/SSC\ CA.crt -keyfile private/ca.key -out newcerts/sec05.crt  

ca Comando para assinar p, gerar

CRL (Listas de Certificados revogados ) e para manter uma base de dados sobre os certificados gerados.

-in sec05.csr Indica o CSR a encriptar. -certs certs/SSC\ CA.crt

Indica a Autoridade de Certificação que vai assinar o CSR.

Parâmetros 

-keyfile private/ca.key

Indica a chave da CA privada.

Comando  Openssl req –new –key private/sec05.key –out sec05.csr  Parâmetros  req  Comando que cria e processa certificados no 

formato PKCS#10.   ‐new  Flag que identifica o comando como criação de um 

novo item.    ‐key 

private/sec05.keyIndica a chave da entidade que solicita o certificado. 

  ‐out sec05.csr  Indica onde ficará o ficheiro resultante deste comando. 

-out newcerts/sec05.crt

Indica o ficheiro resultante de todo este processo, nomeadamente o requerido certificado.

 

5. Ficheiros de configuração 

5.1. openssl.conf      

No  ficheiro  openssl.conf,  situado  na  directoria  /etc/pki/tls,  foi  criada  uma  área  à  qual  se chamou  CA_modded.  Esta  nova  área  é  igual  à  área  por  defeito,  no  que  respeita  a  opções, contudo difere da mesma no aspecto dos directórios, apontando para os directórios utilizados nos testes, como se pode observar na figura 3.  

Figura 3 – Excerto do openssl.conf 

Ao  modificar  o  parâmetro  “dir”  para  /root/ssc,  todos  os  ficheiros  seguintes  tomam  este caminho como raíz. Na tabela seguinte  irão ser explicados as entradas presentes na figura 3, que podem causar mais dúvidas. 

 

certs  Directório onde se encontra a CA 

Crl_dir  Directório  onde  se  encontram  os  ficheiros  correspondentes  às listas de certificados revogados pela CA. 

database  Index.txt  é  o  ficheiro  que  vai  sendo  actualizado  contendo informação de todos os certificados criados e revogados pela CA. 

 

Dentro  da  secção  [req],  procedeu‐se  à  alteração  da  sub‐secção  [req_distinguished_name], onde se alteraram os valores por defeito, para os valores apresentados na figura 4, por forma a tornar mais fácil o preenchimento dos requisitos  requeridos na criação de um novo CSR. 

 Figura 4 – Excerto [req] do ficheiro openssl.conf  

Para  além  das  duas  secções  referidas,  este  ficheiro  não  sofreu  mais  alterações,  quando comparado com o original. 

 

 

 

 

 

 

 

 

 

 

 

 

5.2. httpd.conf  

No ficheiro de configuração do apache. httpd.conf, apenas foram adicionados VirtualHosts na secção 3, como se pode ver na figura 5.  

 

Figura 5 – Secção 3 do ficheiro httpd.conf 

Todos os VirtualHost são ipbased e todos escutam no mesmo porto, obrigando a existência de um NameVirtualHosts para evitar que o acesso a qualquer destino alojado neste servidor, seja redireccionado  sempre  para  o  primeiro  VirtualHosts.  Os  três  VirtualHosts  definidos  têm  a estrutura  idêntica e o objectivo das  suas presenças neste  ficheiro de configuração é apenas para que no caso do cliente aceder a qualquer uma destas áreas via http, seja redireccionado dentro da mesma área, para https. Assim, para cada área definiu‐se um VirtualHost com: 

• Raíz da área. 

• Nome completo da área. 

• Ficheiro de registo de erros, definição de nível de alarme e tipo de registo. 

• Zona de configuração referente à raíz da área com: 

Comando de ligação do modo Rewrite 

Opção para permitir seguir links. 

Regra que permite efectuar o  redireccionamento para a  zona  segura, acompanhada pela flag ‘R’, que força o redireccionamento e pela flag ‘L’, que aplicada a seguir à ‘R’ funciona como um travão parando qualquer comando de reescrita. 

Como  se pode observar na  figura 5, no endereço https é  indicado o porto,  sendo que para aplicar o mod_ssl no apache, os VirtualHosts correspondentes têm de ser  ipbased,  logo esses VirtualHosts utilizados para ligações https, precisam de ser configurados em portos diferentes, pois caso contrário  irão todos carregar o certificado do primeiro VirtualHost, sendo que esta solução é completamente transparente ao cliente.  

No ficheiro ssl.conf irá ser apresentado o resultado deste redireccionamento.  

5.3. ssl.conf  

O ficheiro ssl.conf, ou seja, o ficheiro de configuração correspondente ao módulo que permite implementar o protocolo SSL no apache, não sofreu nenhuma alteração de base, sendo que apenas lhe foram adicionados VirtualHosts, para tratar os redireccionamentos efectuados pela configuração do ficheiro httpd.conf, ou os pedidos directos em https. Para cada VirtualHost foi configurado  as  restrições  de  acesso  à  respectiva  área  e  adicionados  os  Listener  aos  novos portos, nomeadamente o porto 444 e 445. O porto 443 já estava adicionado, visto ser o porto utilizado  por  defeito  nas  ligações  https.  Na  figura  em  baixo  pode‐se  observar  a  primeira alteração, correspondente aos virtualhosts. 

 

Figura 6 – VirualHosts do ficheiro ssl.conf 

 

Em cada virtualHost apresentado, pode‐se começar por verificar as primeiras entradas que são semelhantes  às  apresentadas  no  ficheiro  httpd.conf, mudando,  respectivamente,  apenas  a directoria  e  os  nome  dos  ficheiros  de  log. Mais  abaixo,  entram  as  novidades,  ou  seja,  a indicação de que  aquele  virtualhost utiliza uma  ligação  SSL, o  tipo de  cifras que  suporta, o caminho  do  certificado  emitido  para  aquele  virtualhosts,  a  sua  chave  e  o  caminho  para  o ficheiro que contém a  lista actualizada de certificados revogados.   De notar que neste ponto confirma‐se a existência de um certificado para cada área, devidamente acessível com base na utilização de portos diferentes,  tal como se  irá comprovar nos  testes efectuados no ponto 6 deste relatório. 

Na figura que se segue, pode‐se observar a segunda adicção de comandos ao ficheiro ssl.conf, de forma a garantir a restrições requeridas para a área definida por cada virtualhost. 

 

 

Figura 7 – Configuração para as restrições dos directórios, ficheiro ssl.conf 

Como se pode observar, as condições de acesso são aplicadas directamente á directoria.  

Na  directoria  da  área  sec05.dei.uc.pt  utiliza‐se  o  comando  “SSLVerifyClient  require”  para indicar  que  o  cliente  é  obrigado  a  possuir  um  certificado  para  aceder  à  área,  sendo  este comando completado pelo seguinte, “SSLVerifyDepth 1”, que ao ter o nível 1, indica que esse certificado ou é o certificado self signed da CA, ou é um certificado directamente emitido por esta. No comando “SSLOptions”, a entrada +StrictRequire reforça a  impossibilidade de acesso em caso de falha de validação. 

Para a área ssc05.dei.uc.pt, utilizou‐se a mesma restrição que na área anterior, adicionando‐lhe ainda um filtro maior, através do comando “SSLRequire”. Neste comando, são adicionadas opções de restrição, utilizando um  linguagem complexa resultante da mistura de Perl com C, garantindo o acesso apenas a clientes, cujo Common Name tivesse sido inserido manualmente pelo administrador do servidor, sendo que no caso demonstrado, apenas existe um utilizador com  permissão,  o  utilizador  “rnsilva”. O  acesso  é  ainda  restringido  no  tempo,  através  das variáveis  TIME_WDAY  e  TIME_HOUR,  que  ainda  dentro  do  comando  SSLRequire,  limitam  o acesso aos dias úteis, das 8 às 17horas. 

Por fim a última área, correspondente à área  intra05.dei.uc.pt, que apenas permite o acesso sem qualquer tipo de autenticação a clientes residentes na rede 10.254.0.0/24, através do uso de  comando  específicos  do mod_access,  o  order,  o  deny  e  o  allow.  Assim,  obriga  que  os clientes  de  outras  redes  forneçam,  pelo  menos  dados  de  autenticação  válidos,  login  e password. Esta validação de  login e password é o sistema de autenticação básico do apache, 

implantado pelo mod_auth que fornece neste caso, os comandos AuthType (define o tipo de autenticação [basic|digest]), AuthName (Define a mensagem da janela de login), AuthUserFile (Define o ficheiro que contém os  logins válidos) e Require (Define o tipo de validação, se por utilizador especifico, se por grupo ou se por qualquer individuo autenticado com êxito).  

O  comando  “Satisfy  any”  é  o  responsável  por  esta  flexibilidade  entre  o  mod_access  e  o mod_auth, permitindo o acesso à área apenas com o sucesso de uma das condições. No caso do cliente possuir um certificado,  também o pode utilizar opcionalmente para autenticação, sendo que neste caso deveria prescindir da autenticação via login o que não acontece, sendo este caso fundamentado nos pontos 6 e 7 deste relatório. 

6. Testes 

6.1. Área ssc05.dei.uc.pt 

1.1.1.   6.1.1. Acesso válido.   Neste ponto, vai‐se demonstrar o processamento de um acesso válido à área   ssc05.dei.uc.pt. 

O utilizador rnsilva possuí um certificado gerado pela CA e adicionou‐o ao seu browser, como se pode ver na figura 8. 

 

  Figura 8 – Certificado do cliente 

Ao inserir o endereço no browser e clicar no ENTER, 

 

 

Figura 9 – Inserção do endereço. 

o cliente recebe uma  janela de notificação, a questionar sobre a aceitação de  ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 10. 

 

Figura 10 – Notificação de certificado emitido por autoridade desconhecida. 

 

Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o 

seu  certificado  automaticamente,  este  processo  ser‐lhe‐á  transparente,  caso  contrário aparecerá a seguinte janela: 

 

Figura 11 – Janela de solicitação de certificado. 

Nesta janela o cliente poderá escolher o certificado a enviar. 

Como o acesso foi efectuado pelo cliente rnsilva, que foi adicionado pelo administrador á lista dos utilizadores com acesso, com demonstrado na figura x e ainda, ocorreu a uma sexta‐feira às 16:22 da tarde, o cliente tem pleno acesso à área ssc05.dei.uc.pt. 

 

Figura 12 – Excerto do ficheiro ssl.conf 

   

6.1.2.  Acesso de cliente sem autorização ou fora de tempo    

Neste ponto   vai‐se mostrar a tentativa de acesso de um cliente, que mesmo com certificado válido, não acede à área, pois o seu nome não consta da lista gerida pelo administrador. Para efectuar  este  teste,    alterou‐se  a  lista de  utilizadores  autorizados  e  efectuou‐se  o  acesso  à área. Na figura em baixo pode‐se observar a alteração  efectuada.  

 

 

Figura 13 ‐ Excerto do ficheiro ssl.conf modificado para teste 

Como o utilizador “rnsilva” não consta da lista, logo não terá acesso à área, resultando no log de erros do servidor, a seguinte mensagem. 

 

Esta  mensagem  refere  que  falhou  uma  condição  requerida  pelo  comando  SSLRequire, acontecendo o mesmo quando o utilizador, mesmo que autorizado pelo administrador e com certificado,  tente  aceder  fora de horas ou  fora dos dias úteis. Uma parte dessa  condição é também demonstrada na  figura de cima, visto que para conseguir efectuar um  teste no dia corrente, foi necessário alterar o valor de “TIME_WDAY” de 5 para 6, englobando para além dos dias úteis, o sábado. 

Mantendo o sábado como dia válido, alterou‐se a hora final, em “TIME_HOUR” de 17 para 12, e voltou‐se a adicionar o utilizador rnsilva à lista de permissões, como demonstra na figura em baixo. 

 

Figura 14 ‐ Excerto do ficheiro ssl.conf modificado para teste 

Ora, deste modo e visto que o teste decorre precisamente às 13:52, o acesso foi bloqueado e nova mensagem adicionada no ficheiro de log, demonstrado na figura seguinte.

 

Figura 15 – Ficheiro de log de erros da área ssc05 

Por fim repuseram‐se os valores correctos,definidos pelo enunciado,  e tentou‐se efectuar o acesso ao sábado, que falhando, levou novamente à análise do ficheiro de log de erros, onde mais uma vez foi adicionada uma linha de erro relativamente à falta de um requerimento do SSL. 

  Figura 16 ‐ Ficheiro de log de erros da área ssc05 

 

De notar, que estes testes foram efectuados todos no mesmo dia e pela mesma altura, o que levou a realizar uma situação inversa de teste, ou seja, a alteração dos ficheiros de configuração, para garantir o funcionamento das restrições, nele inseridas. Com a ajuda dos ficheiros de log, é possível observar as datas precisas do teste. 

  6.1.3. Acesso sem certificado  

O  cliente  introduz  o  endereço  da  área  no  seu  browser  e  ao  tentar  aceder  à  área  sem  o certificado, o acesso é negado, ficando registado no log  de erros a seguinte entrada. 

 

Figura 18 ‐ Ficheiro de log de erros da área ssc05 

O erro apresentado na imagem em cima, é igual para a tentativa de acesso a qualquer das áreas apresentadas neste relatório, que obrigam a que o cliente apresente um certificado emitido pela CA privada e este não o possuí. 

 

6.2. Área sec05.dei.uc.pt 

6.2.1. Acesso com certificado emitido pela CA privada  

O utilizador rnsilva possuí um certificado gerado pela CA e adicionou‐o ao seu browser, como se pode ver na figura 19. 

 

  Figura 19 – Certificado do cliente. 

Ao  inserir  o  endereço  no  browser  e  clicar  no  ENTER,  o  cliente  recebe  uma  janela  de notificação, a questionar sobre a aceitação de  ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 20. 

Figura 20 – Notificação de certificado desconhecido. 

Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o seu  certificado  automaticamente,  este  processo  ser‐lhe‐á  transparente,  caso  contrário aparecerá a seguinte janela: 

 

Figura 21 – Janela de selecção de certificado do lado do cliente. 

Nesta janela o cliente poderá escolher o certificado a enviar. 

Ao clicar em OK  terá acesso à área, pois o  seu certificado  foi directamente emitido pela CA privada. 

Figura 17 – Página segura da área sec05 

 

6.3. Área intra05.dei.uc.pt    

6.3.1.  Acesso a partir da rede 10.254.0.0/24  

Com a tentativa de acesso a partir da rede 10.254.0.0/24, o cliente não necessita de qualquer tipo  de  autenticação,  nem  de  certificado,  sendo  directamente  redireccionado  para  a  área segura. O código apresentado na figura em baixo é o responsável por essa acção. 

 

 

Figura 22 – Página da zona segura de intra05. 

6.3.2.  Acesso com login e password  

Quando  o  utilizador  não  se  encontra  na  10.254.0.0/24  e  não  apresenta  certifcado,  é  lhe apresentada uma janela, para que este insira os seus dados de login, dados esses previamente adicionados pelo administrador , a um ficheiro especifico com o comando  

htpasswd ‐c /var/www/passwd/passwords rnsilva ou  

htpasswd  /var/www/passwd/passwords rnsilva, caso o ficheiro já tenha sido criado. 

 

Figura 23 – Ip fora da rede 10.254.0.0 e pedido de autenticação. 

Ao introduzir as suas credenciais válidas, o utilizador tem então acesso à área. 

 

Figura 24 – Entrada na zona segura de intra05 com sucesso. 

Caso o utilizador insira as credenciais erradas, a janela de pedido dessas credenciais, teima sempre em voltar a aparecer, sendo a única opção do cliente que não tem credenciais, cancelar essa janela, aparecendo‐lhe a seguinte mensagem. 

 

Figura 25 – Autorização negada a utilizador inválido. 

Acompanhado com essa mensagem, fica registado no log de erro, o erro 401 que significa que existiu uma tentativa de acesso não autorizada, a uma zona que o exigia. 

6.4.   Acesso com certificado revogado  

Para além de  todas as  restrições especificas por cada área, o  servidor configurado,  também verifica se os certificados que os clientes estão a tentar utilizar para aceder a cada área, não se encontram  revogados.  Para  revogar  um  certificado  o  administrador  utiliza  os  comandos demonstrados na figura seguinte: 

 

Figura 26 – exemplo e comprovação da acção de revogação de um certificado. 

Na  figura,  está  demonstrado  a  verde  o  comando  de  revogação  do  certificado  rnsilva.crt,  a amarelo  está  o  comando  que  gera  o  ficheiro  com  a  lista  dos  certificados  revogados  e  a vermelho o contéudo desse ficheiro. 

Como na configuração do ficheiro ssl.conf, foi adicionada a linha : 

SSLCARevocationFile    /root/ssc/crl/upd1.crl, que  faz  com que o  servidor quando  recebe um certificado, verifica se este está na lista dos certificados revogados. 

Como cenário de teste revogou‐se o certificado do utilizador rnsilva, sendo que quando este tentou  aceder,  posteriormente,  à  área  sec05.dei.uc.pt  (que  apenas  requer  em  certificado válido),  esse  acesso  é  negado  e  fica  registado  no  log  uma mensagem,  como  demonstra  a seguinte figura. 

 

Figura 27 – ficheiro log da área sec05.dei.uc.pt 

7. Funcionalidades não implementadas  

No desenvolvimento de trabalho ficaram três pontos por afinar, nomeadamente: 

Revogações detectadas por directório e não por ficheiro. 

Lista de clientes com acesso à ssc05.dei.uc.pt contida num ficheiro específico, em vez de ser inserido manualmente no ficheiro de configuração. 

No acesso à área  intra05.dei.uc.pt mesmo que o utilizador apresente certificado  ,  terá sempre que inserir as credenciais de acesso. 

Ora, em relação ao primeiro ponto, todo o processo estudado para implementar o sistema de analise das revogações através da directoria  foi implementado, quando algum detalhe deverá estar a faltar, pois o sistema não funciona. Os passos seguidos foram: 

• Criar o directório e colocar lá os ficheiros *.crl criados. 

• Efectuar o link simbólico para cada um através do comando:   

 ln ‐s upd1.crl `openssl crl ‐hash ‐noout ‐in upd1.crl`.r0 

ou com o makefile fornecido juntamente com o mod_ssl. 

• Inserir o comando SSLCARevocationPath /root/ssc/crl/ no ficheiro de configuração.

No  segundo  ponto,    tentou‐se  efectuar  a  inserção  dos  utilizadores  válidos  num  ficheiro, através  de  dois modos. Um  utilizando  a  função  file(“path”),  definido  na  documentação  do mod_ssl para o  comando  SSLRequire e o outro utilizando uma  interacção  com o mod_auth 

tentando criar um sistema de autenticação apenas com o username. Contudo nenhuma destas tentativas  se  tornou  solução,  sendo que optou‐se por utilizar  a  solução  implementada, que para  o  contexto  de  teste  é  viável,  ao  contrário  de  casos  reais  em  que  a  lista  de  acessos permitidos seja de larga escala. Com certeza que existirá uma solução bem viável, mas que no contexto da realização deste trabalho, não foi encontrada. 

No  terceiro ponto, em que definido pelo enunciado, o acesso à  zona  intra05.dei.uc.pt, para utilizadores  fora da rede 10.254.0.0/24, seria permitido consoante uma de duas hipóteses, a apresentação de um certificado válido ou a  introdução de credenciais, username e password, caso  não  existi‐se  um  certificado  válido.  É  entre  estas  duas  hipóteses  que  o  sistema implementado  falha,  pois  nos  testes  realizados,  mesmo  que  o  utilizador  apresente  um certificado  válido,  o  sistema  pede‐lhe  sempre  as  credenciais  de  login.  Uma  solução teoricamente possível seria a utilização do comando “Satify any” que tão bem funciona entre o mod_access  e  o mod_auth, mas  que  com  o mod_ssl  não mantém  o mesmo  nível.  Deverá contudo  existir  uma  condição  que  permita  evitar  que  o  cliente  seja  obrigado  a  inserir  as credenciais, quando já emitiu um certificado válido. 

8. Conclusão   

Este  trabalho consistia na emissão de certificados e configuração de  servidores apache para acesso  seguro,  utilizando  o  mod_ssl.  É  uma  área  importante  que  actualmente  permite restringir o acesso e possibilitar acções de grande importância, sobre uma rede aberta, como a internet.  

Ao  realizar  este  trabalho,  o  grupo,  adquiriu  variados  conceitos  dentro  desta  área  e  tomou noção  e  contacto  com  a  configuração  completamente manual  que  estes  sistemas  exigem. Deparou‐se  também  como  uma  vasta  documentação,  do  apache  e  dos  vários  módulos, contudo existem pontos específicos pouco fundamentados e com poucos “How to’s”, como no caso do comando SSLRequire, que segundo a documentação parece ter enorme potencial, mas que  com  a  sua difícil  linguagem de  configuração  requer um  conhecimento  algo profundo  e alguma prática, para dele retirar todo o proveito. 

Assim, dá‐se por concluído este  trabalho e  fica‐se  com o conhecimento destas  ferramentas, ficando a base para uma futura evolução neste campo. 

 

 

 

 

 

9. Bibliografia  

[http06] http://httpd.apache.org/docs/2.0/mod/core.html

[mod_ssl06] http://httpd.apache.org/docs/2.0/mod/mod_ssl.html

[mod_auth06] http://httpd.apache.org/docs/2.0/mod/mod_auth.html

[mod_rewrite06] http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html

[mod_access06] http://httpd.apache.org/docs/2.0/mod/mod_access.html

[ssl06] http://modssl.org/docs/2.8/ssl_howto.html

[crl01] http://www.apacheweek.com/features/crl

[apache00] http://www.vanemery.com/Linux/Apache/apache‐SSL.html