дыра в безопасности в GSSContext метод acceptSecContext? (ДЖАВА) - PullRequest
Новая
       36

дыра в безопасности в GSSContext метод acceptSecContext? (ДЖАВА)

0 голосов
/ 28 июня 2018

Когда билет службы, сгенерированный клиентом, отправляется на сервер, метод GSSContext acceptSecContext должен декодировать такой билет, который был закодирован KDC.

когда этот метод вызывается с сервисным билетом в качестве его параметра, действительно ли тикет отправляется самому KDC для декодирования?

В противном случае это не будет проблемой безопасности? потому что, если сервер может декодировать любой действительный билет, о котором он ничего не знает, кроме какого-то отправленного ему клиента или для чего или для кого предназначен билет?

немного смущен

Любые разъяснения приветствуются.

Я читал, что Сервер приложений и KDC общаются, но я не думаю, что это всегда так.

например, взгляните на пример кода сервера

Сервер приложений входит в систему, чтобы получить контекст 

LoginContext loginCtx = null;
loginCtx = new LoginContext("SPN", new LoginCallbackHandler( id, password ));
loginCtx.login();
Subject subject = loginCtx.getSubject();

затем, используя этот sujbect, он выполнит превалирующий doAs 

Subject.doAs( subject, new PrivilegedAction<String>() {
  public void run() {
    try {
        GSSManager manager = GSSManager.getInstance();
        GSSContext context = manager.createContext( (GSSCredential) null);
        context.acceptSecContext( serviceTicket, 0, serviceTicket.length);
        // now do something with decoded ticket 
    }
...
}

1 Ответ

0 голосов
/ 28 июня 2018

действительно ли билет отправляется на сам KDC для декодирования?

Нет, сервер приложений и KDC не связываются.

Вот почему вы должны скопировать keytab, сгенерированный на KDC, на сервер приложений перед использованием системы.

Сервер пытается расшифровать билет, и если он может это сделать, то он предполагает, что билет был сгенерирован KDC, потому что он единственный человек , который знает пароль, тогда это действительный билет.

Предварительный обмен ключами / паролями до того, как система будет эффективно включена, а затем никогда не отправлять его по сети, является распространенным механизмом во многих протоколах аутентификации, например,

...